ßødincµs wrote:
> Gordon Henderson wrote:
>>> If this happens regularly with registrations to an Asterisk-based
>>> server, probably the setup is incorrect.
>>
>> I really don't think it is.
> Well, it doesn't happen to me with 35 S450IP registered onto 12 Trixbox
> based PBXes, both internal and external. so I should be doing something
> right...
>
>>> 1. Do you have all the necessary ports forwarding in place on the
>>> router from the public IP to to the phone private IP (5060-5070 and
>>> 5004-5010 UDP)? If not, set them up.
>> Yes. As I said, the phones work for some time - days/weeks depending on
>> how busy they are. I know (from reading some forums on the Siemens sites)
>> that I'm not alone with this issue.

Are you sure it's the same issue? I've read about issues where phones
fail to re-register after an Internet connection has been down for a
short while until rebooted (only an issue with a hosted PBX though).
This is an issue I have been trying to replicate in my office without
much luck but I've had a couple of people reporting it, Siemens
developer guys in Germany are also looking into it as we speak.

> How "busy" are the phones?
>
>> And note that this is also a problem with phones on the same LAN as the
>> PBX, so no nat/stun/anything needed in these phones, yet the same thing
>> happens; the phones indicate that they are still registerd, asterisk
>> shows them to be still regsiterd, but the phones reject calls and can't
>> make VoIP calls either. The analogue side seems unnaffected.
> Can I see a trace of a failed inbound call?

Me too! Or a trace of when an outbound call is attempted...

>
>>> 2. Is the phone base onto a static IP (highly recommended)? If not,
>>> assign it a private static IP in the range of the router BUT NOT IN
>>> THE ROUTER DHCP RANGE.
>> Why?
> Well, if you don't know why it's better you do it without asking, innit?
> ;-)

The only reason to use static IPs would be to make manual administration
of the units easier. There's absolutely no reason to have SIP UAs on
static IPs when they are registering to the server, half the point of
the registration process is so the server knows the UA's IP address.

>
>>> 3. What method do you use to do NAT traversal, STUN or Outbound
>>> Proxy? Asterisk isn't happy to be the outbound proxy, so you need a
>>> STUN server to let the Siemens know its own public IP and properly
>>> populate the SIP REGISTER message with the public IP, not its own
>>> internal IP.
>> I run my own stun server.
> How often the Siemens poll the STUN server?

In my experience STUN rarely works anyway, all it does is allow a device
to find out what type of NAT it is behind. Since Gordon has said that
these phones are already on the same network as the Asterisk box,
there's no need for STUN, outbound proxy or any of that anyway.

>
>>> 4. Do you have - by any chance - the "qualify=yes" parameter in the
>>> extension definition? Take it off.
>> Why?
> It's an unnecessary burden on the SIP channel and can lead to memory
> leaks in the Siemens.

Memory leaks? I'm very interested in some evidence of that, can you
contact me off list if you have experienced this and have some evidence
of why you think it's caused a memory leak? paul@ the domain in my From
address.

>
>>> 5. Look at the full Asterisk log (/var/log/asterisk/full) to see if
>>> you have any strange activity from the phones (look for 45x codes).
>> That's an implmentation dependant log-file and not present on my
>> systems, however there is a string of 405 errors from these phones, but
>> I'm led to beilive that're "mostly harmles":
>>
>> -- Got SIP response 405 "Method Not Allowed" back from 192.168.0.36
>> -- Got SIP response 405 "Method Not Allowed" back from 192.168.0.35
> The Siemens phone is telling you that something your SIP server does is
> wrong. Again, that doesn't happen to me.
> Errors can lead to memory leaks and then the obvious OS / SIP stack
> crash in the base unit.
>

These aren't errors, they are responses. They happen when Asterisk send
a Subscribe message to the Siemens phone, because the Siemens phone
doesn't support Subscribe/Notify at the moment. Again, where is this
talk of memory leaks coming from?

>>> Power cycling the base will dramatically shorten the lifespan of the
>>> PSU. They have a high mortality rate when they cool off and warm up
>>> again repeatedly.
>> Maybe, but I have no choice in this matter right now. (Other than waste
>> more money on this client and replace 6 Siemens units with 6 Snom units
>> and 4 extra handsets)
> Your immediate choice is obvious, buy a timer and powercycle the base
> unit. In the long run however, keep a close eye on the issues I pointed
> out to you, you may find a solution.
>
>>> Caveat emptor: I never dealt with C450IPs, we use S450IPs. The
>>> firmware and the base unit should be the same tho...

No, the C460IP and S450IP have different hardware and different firmware
in the base station.

cheers,
Paul.