SPA112 not picking up DHCP and cant set via IVR

[Sage Major]

Firmware 1.2.1.004

I have 2 spa112's that came back from the field

Neither of them will pick up an ip address via DHCP, I tried on multiple routers.  The ivr 110# says 0.0.0.0

I also tried setting the ip to static via IVR

101# 1# (this sets to static ip)

111# it says is invalid (It should let me set the ip based on page 7 of the manual)

121# it says is invalid (It should let me set the netmask based on page 7 of the manual)

Are these defective?  One was working for 2 weeks the other failed at install time however it did work when we provisioned it.

[WRFan]

This is definitely the last time I've ever bought a Cisco product. This SIP ATA is absolutely pathetic. The guy above is completely correct about saying the IP of the ATA cannot be set to static using IVR. This is due to the fact that this morose device needs to have SOME ip before it can be set to static. If you have no DHCP server running on your network (and I don't, don't need one, I assign my IPs manually), then obviously SPA112 will have no IP assigned, so IVR says "invalid" when trying to change to static over IVR. Someone said above "The fix was to connect to the LAN port of a Grandstream Handytone 486 which has a DHCP server built in." Yes, that's exactly what we are forced to do, because Cisco is so INCREDIBLY INCREDIBLY incompetent, we are forced to set up a DHCP server, just to change a IP address. So I downloaded some crap dhcp server off the net, started it, it assigned an IP to SPA112, then I was able to set a static IP. Has the world ever witnessed such incredible incompetence?!

Someone else above said, "All I can say is - it works for me... Even if you are unable to use DHCP to assign IP address, even if you are unable to set static IP via IVR, the phone still can be configured via WWW according your wishes." Pal, exactly how can you access the device "via WWW" if the device doesn't have an IP? It works for you, because most probably you are using one of those pathetic router boxes ISPs throw at their customers, and those have a DHCP server built-in. It is obvious, you have no knowledge of networking, that's all right, but then please don't interfere in technical discussions.

Now, this was problem Nr. 1. Now for problem Nr. 2. Cisco advertises this ATA as "ipv6 capable", but that doesn't mean it actually supports ipv6, that would require a firmware update... yet Cisco never added this functionality! I say "never added" as in "past tense", because Cisco announced it's dropping support for this device - check the SPA112 page on Cisco's webpage. Great tactics, Cisco! You were promising to add this functionality, so people have been buying this device in good faith, hoping you'd add it, so you promised, promised, then puff! ceased support! Made some money on us, Cisco-baby? Well, never again, I promise you this. Now, please, enter the following on your computer:

nslookup ssl85-v6.telefon.unitymedia.de

Name: ssl85-v6.telefon.unitymedia.de
Address: 2a02:908:a:1000::43

Look, there's no ipv4 address! May I introduce my ISP's sip server to you? That's what they assigned me to. Amazon said the device is ipv6 capable. Well, they just stated what Cisco claimed, can't blame Amazon, it's Cisco who's lying and deceiving.

So I called my ISP and told them that Cisco is a pathetic company. They told me, they were not affiliated with Cisco and didn't give a **bleep** about my problems OR Cisco. Of course, they didn't even understand a word of what I was telling them, they just kept repeating, "You have Dual Stack, so you can access ipv6 addresses" or "Use our cool Teredo tunnel to access ipv6 addresses!" I was obviously talking to cretins, I was stupid enough to make an attempt at explaining, stating that, yes, I do have Dual Stack, and yes, all of my devices are able to access ipv6 addresses, but there's just this tiny problem that Cisco is deceiving its customers and selling a ipv4-only device as ipv6-capable. "No problem," they reply, you have "Dual Stack!" Sigh.

So I told them to assign me to another sip server, because they have some that have an ipv4 address either. They told me, they couldn't assign me to a specific server, they can only re-create my SIP account, but there's no guarantee I'd be assigned to a server that is ipv4-capable (they are obviously not in control of their system, but their system controls THEM).

So what am I supposed to do, when surrounded by deceivers and cretins? I tell them, recreate the **bleep** account. Waited for 3 days, they finally assigned me to another server, for once in my life I got lucky and actually got an ipv4-capable server.

Obviously, I didn't have a working SIP connection during all this time of troubles, so I had to make all calls (including those to my ISP) through my mobile carrier, that was real cheap! Just 50,-€! Isn't that cheap, Cisco? Are you going to give me that money back, dear Cisco? No? Well, that's a surprise, because my ISP is not paying me back anything either, although ipv6-only servers are a joke in a world which still hasn't made a jump to ipv6, we've been talking about this for 30 years, but alas.

So I finally set up the SIP ATA. The config features 10.000 settings, and my ISP is not saying ANYTHING, they tell you to use the manual of the device, exactly how is Cisco supposed to know the settings Vodafone's sip servers expect?!!! For once, it's not Cisco's fault, but my ISP's.

Got an "Internal Error" trying to connect, turns out I had to set "RTP Packet Size" to "0.020", of course, ISP is not saying anything, found the info by accident on the internet. **bleep** Vodafone.

So, ok, I was enjoying my SIP phone calls for some time, then I had some problem with my internet connection, called the ISP, they sent a technician, the problem got fixed, but as a result, they moved me to another SIP server. So I crossed my fingers, hoping I'd get an ipv4-capable server this time. So I get my data, and indeed, I got assigned to a server with an ipv4 address. So I am like, great, got lucky again. So I add the new server/password to SPA112, try to make a call, not ringing. Call the SIP box from my mobile phone, phone connected to Cisco's box not ringing. What the hell is going on?

Was checking Wireshark output for 3 (!) days. Turns out my ISP is too stupid to set up their SIP servers. Now listen up REAL carefully, 'cause it's **bleep** complicated and check with:

https://tools.ietf.org/html/rfc3261
https://tools.ietf.org/html/rfc2327
https://tools.ietf.org/html/rfc1889

while I explain. Below, "192.168.0.14" is the IP address of the SPA112 on my LAN, "80.69.110.121" the IP of the SIP server, that was configured correctly, "80.69.110.103" has faulty configuration, "XXX.XXX.XXX.XXX" the global address of my router.

The previous server I was on was working, because it was sending replies to the port from which it received the "REGISTER" request. This is obviously vital due to NAT, since the SPA112 is sending the "REGISTER" on port 5060, but it's NAT-ted to the SIP server over some other port.

SPA112:

Src Port: 5060, Dst Port: 5060

192.168.0.14 80.69.110.121 SIP Request: REGISTER sip:ssl104ds.telefon.unitymedia.de (1 binding)

Via: SIP/2.0/UDP 192.168.0.14:5060;branch=XXX-XXX

Transport: UDP

Sent-by Address: 192.168.0.14

Sent-by port: 5060

My Router NAT-ting:

Src Port: 65530, Dst Port: 5060

ISP answering to ROUTER port (65530, NOT 5060!):

Src Port: 5060, Dst Port: 65530
80.69.110.121 XXX.XXX.XXX.XXX SIP Status: 100 Trying

Now check out what the new SIP server of my ISP is doing:

Src Port: 5060, Dst Port: 5060
80.69.110.103 XXX.XXX.XXX.XXX SIP Status: 100 Trying
80.69.110.103 XXX.XXX.XXX.XXX SIP Status: 407 Proxy Authentication Required

**bleep** stupidity, they are trying to communicate with the SPA112 directly! Of course, the "Proxy Authentication Required" never reached the Cisco box, so no Authentication, no calls for me.

Now Cisco, I know what you are going to say, "How is this our fault?" It IS your fault, because if SPA112 were ipv6 capable, it would have a global ipv6 address and the SIP server (even though it's not configured properly, but that's my ISP's fault), would still be able to communicate with the SIP ATA, because, obviously, ipv6 doesn't require NAT. So it also comes down to ipv6 again, or rather, it all comes down to Cisco's greed again. You know, Cisco, Famine was once so hungry, it ate everything up, and when nothing was left it could nourish upon, it nourished on itself. Take care lest your greed doesn't nourish on you.

Now I found a setting in the SPA112 that's called "Insert VIA received". Of course, you have to be an expert on the SIP protocol to even understand what it does. Wireshark is your friend here. If this setting is enabled:

SPA112:

Src Port: 5060, Dst Port: 5060
192.168.0.14 80.69.110.103 SIP Request: REGISTER sip:ssl93-ds.telefon.unitymedia.de (1 binding)
Via: SIP/2.0/UDP 192.168.0.14:5060;branch=XXX-XXX;rport
RPort: rport

See the difference? SPA112 is sending "rport". Stupid ISP server finally realizes it has to send to router port, NOT 5060:

Src Port: 5060, Dst Port: 52891
80.69.110.103 XXX.XXX.XXX.XXX SIP Status: 100 Trying
Via: SIP/2.0/UDP 192.168.0.14:5060;received=XXX.XXX.XXX.XXX;branch=XXX-XXX;rport=52891

80.69.110.103 192.168.0.14 SIP Status: 200 Registration Successful (1 binding)

Now you think this solved the problem? Sure as hell it didn't. I was able to proxy authenticate with the SIP server, yet still no calling, neither outbound, nor inbound, because the outbound "INVITE" SIP/SDP Request was replied to port 5060 again (NOT the port used by NAT router), so again, never reached the SIP ATA. Even more interesting, the inbound calls never arrived. Now I was going nuts trying to understand, why the incoming calls never arrived, not even at the NAT router! Then it finally occurred to me... the SIP server was sending the "Invite" to "192.168.0.14", just the ip address of the SIP ATA on my local network. Has anyone ever witnessed such utter stupidity?! Suffice to say, the fault is not on my side, since my setup hasn't changed and was working just fine with the SIP server I was assigned to before. That server was properly configured, so it was pushing the call to the global address of my router, not the SIP ATA. Pushing is the proper word here, since this whole procedure is not that different from Apple's Push Notification Service (APNS), com.apple.apsd.

So what to do, what to do? I called my ISP and told them to fix their **bleep** server. They tell me, they'll open a ticket and address the issue. Next thing I witness is a **bleep** technician calling on my door. What the hell do you want? Me? I am here to fix your phone. So I told him to get lost, go fix your own **bleep** server! So he got lost, and surprise! the ISP server never got fixed. Should I laugh or cry now?

So what now? **bleep** port forwarding, great. So I enable port forwarding for port 5060, still not working. What the hell? Why, of course, RTP packets are sent to the port of the SIP ATA, NOT the port the NAT router was actually using, so:

80.69.110.103 XXX.XXX.XXX.XXX RTP
Src Port: 40912, Dst Port: 16386

Great, so set port forwarding for ports 16384-16390, plus:

SIP -> RTP Port Max: 16390

Because you don't want to port forward 200 ports (this is the minimal number you can set, Port Max must be an even number, consult the manual).

Plus, of course, you have to tell the **bleep** SIP server (SPA112 settings) to:

SIP -> "Handle VIA received": i.e., use the **bleep** External IP.

Line 1 -> NAT Mapping Enable (so SPA112 sends a global IP to the SIP server):

Via: SIP/2.0/UDP 192.168.0.14:5060;received=XXX.XXX.XXX.XXX;branch=XXX-XXX;rport=57637
Contact URI Host Part: XXX.XXX.XXX.XXX

So great, ISP SIP server calls coming through, but you know, who else is coming through? Hackers. Yep. Cisco and Vodafone care about your privacy! Because before I enabled port forwarding, all morons trying to SIP-reach me at port 5060 got a "Destination unreachable" in their faces, but now all requests get forwarded to the SIP ATA. Cause NAT got a hole at 5060 and at RTP ports. Thank you Cisco! So if some guy steals your SIP credentials and uses them to sell child porn, it's you who gets the credit. Just fire up Wireshark and you'll notice those nice people hammering your IP, asking for SIP credentials, inviting you to answer calls (probably to tell you've won 1.000.000$, lol). You think Cisco will take the blame on themselves? Oh, poor customer, we handle this for you! Yep. You bet! Cisco cares about their customers!

So there's this option:

Line 1 -> Restrict Source IP: yes

So enabling it makes SPA112 shut up and ignore all requests by anybody except SIP proxy (basically your SIP server; but the consortium called it "proxy" to confuse you. yep.).

So recently I checked Ebay, and they are selling a brandnew Grandstream HT802 (supports ipv6!!!) for 25,-€. I paid over 30,-€ for this pathetic SPA112. So looking at the Ebay page I was thinking how nice it would be if Cisco were obliterated from reality. Could you do us this little favour, Cisco, and obliterate yourself?

So again, I'd like to thank Cisco and my wonderful ISP for making this experience possible! I am overjoyed! Any time, Cisco, any time! I hear you got a brandnew SIP ATA, which you released to replace that old useless SPA112. Cool! I am off to Amazon! To buy Cisco stuff! The coolest company on earth!

[Dan Lukes]

Well, I feel your deep frustration. Everybody is trying to make your life worse. Cisco have buggy product, someone trying to help have pathetic router, your ISP is too stupid. You are barking up to wrong tree, my friend. There's no Cisco representative listening here, so you are wasting your time.

It seems you have an issue. Members of this community are ready to help you to found a solution. Or workaround. If you are calling for help. But it seems you just wish to inform us that all other people around you are stupid - it's something we can't help you with. Just because we are too stupid, you know. So sorry for this. I swear we will try to work hard to improve our skills.