UKVoIPTalk.com

Jose wrote:[color=blue]
> On Wed, 26 Mar 2008 19:51:17 +0000 (UTC), Gordon Henderson
> <gordon+usenet@drogon.net> wrote:
>
>[color=green]
>> Unfortunately, the calibre of staff in these (volenteer, charity) shops
>> means that asking them to power cycle the base stations when they stop
>> working, is a bit beyond them. It's now almost at the point where they're
>> probably going to ask me to replace them or give them their money back.[/color]
>
> Do you mean:
>
> 1) just switching the handset off/on, or
>
> 2) switching off/on the power to the base stations?
>
> If number 2, you could connect the AC adapter to timer/watch plug,
> that would switch off/on the power to the base unit every night.
>[/color]

That presumes a certain type of fault.

It may be that the crashes are actually random and not connected to how
long the phone has been on. With an intermittent bug it is hard to tell.


[color=blue]
>[/color]

In article <47EB8B52.8080008@this.email>, ßødincµs <nobody@this.email> wrote:[color=blue]
>Gordon Henderson wrote:[color=green]
>> Interesting issues - thanks. I always use a PBX, so lack of LCR, dialplan,
>> etc. isn't an issue. Shame you need to flash it immediately too, but I
>> can live with that.[/color]
>It's not an issue, it's easy and painlessly done through the handset -
>no need for a PC on the same network.
>And as every SNOM phone you can provision them through a properly hand
>crafted text file.
>[color=green][color=darkred]
>>> Personally I've never had problems with Siemens Gigaset phones
>>> (specifically the S450IP). Especially the last firmware release is
>>> pretty stable and reliable.[/color]
>>
>> What I need isn't "pretty stable", it's "rock solid". Right now, I
>> have one company with 6 Siemens C450IP's - all flashed to the latest
>> firmware - 3 in the main office, 3 in 3 remote shops. The shop ones use
>> both their analogue and VoIP ports, the main office, VoIP only. All of
>> them are fairly busy, especially the remote shop ones, although mostly
>> with analogue calls. What I see is about once a week, maybe more, the
>> phones stop working on the VoIP side. The analogue side is fine.[/color][/color]
[color=blue]
>If this happens regularly with registrations to an Asterisk-based
>server, probably the setup is incorrect.[/color]

I really don't think it is.
[color=blue]
>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.[/color]

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.

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.

[color=blue]
>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.[/color]

Why?
[color=blue]
>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.[/color]

I run my own stun server.
[color=blue]
>4. Do you have - by any chance - the "qualify=yes" parameter in the
>extension definition? Take it off.[/color]

Why?
[color=blue]
>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).[/color]

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
[color=blue]
>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.[/color]

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)
[color=blue]
>Caveat emptor: I never dealt with C450IPs, we use S450IPs. The firmware
>and the base unit should be the same tho...[/color]

FWIW: I make/sell/install asterisk based PBXs. I have dozens of boxes
out there and 100's (1000's? I don't know what my resellers get up to)
of phones connected to them, on-site and off-site. The Siemens phones
are the only ones that give me regular problems. (can't speak for the
resellers though) So I'm not going to buy any more Siemens phones (of
any type) until I get a resolution on this issue.

Gordon

On Thu, 27 Mar 2008 10:36:48 +0000 (UTC), Gordon Henderson
<gordon+usenet@drogon.net> wrote:
[color=blue][color=green]
>>If so, does these come any cheaper than cordless phones with 2 line
>>capacity, with an ATA feeding one of the lines, for Voip?[/color]
>
>Well... I did try them with ATAs originally, but they couldn't get on
>with them. Claimed they never worked (and, as usual, every time I tried
>them, they worked jsut fine) By then, I'd installed Siemens ones in HQ
>who just needed the SIP side of things, (analogue was handled by one of
>my asterisk PBXs), so the shops wanted the same handsets, so we got 3
>more for the shops, and they've been nothing but trouble, ever since.[/color]

I see what you mean... Money wyse, how about and SPA3102, or similar
stuff from Gransdstream, plus an ordinary cordless phone?


[color=blue]
>Now to wander up to the local electrical shoppie and look for 4 timers!
>(the 3 in HQ are all on the same power strip)[/color]

Good luck!

Jose

On Thu, 27 Mar 2008 12:35:07 +0000 (UTC), Gordon Henderson
<gordon+usenet@drogon.net> wrote:
[color=blue]
> The Siemens phones
>are the only ones that give me regular problems. (can't speak for the
>resellers though) So I'm not going to buy any more Siemens phones (of
>any type) until I get a resolution on this issue.[/color]

Smart choice: time really is money, and more things than money can
buy.

I'd sell you Gransdtreams FXO + FXS ATAs, and reliable cordless
phones, if I had a business near you ;-)

Jose

In article <47eca08b.11482343@news20.forteinc.com>,
Jose <go.spam@somewhere.else> wrote:[color=blue]
>On Thu, 27 Mar 2008 10:36:48 +0000 (UTC), Gordon Henderson
><gordon+usenet@drogon.net> wrote:
>[color=green][color=darkred]
>>>If so, does these come any cheaper than cordless phones with 2 line
>>>capacity, with an ATA feeding one of the lines, for Voip?[/color]
>>
>>Well... I did try them with ATAs originally, but they couldn't get on
>>with them. Claimed they never worked (and, as usual, every time I tried
>>them, they worked jsut fine) By then, I'd installed Siemens ones in HQ
>>who just needed the SIP side of things, (analogue was handled by one of
>>my asterisk PBXs), so the shops wanted the same handsets, so we got 3
>>more for the shops, and they've been nothing but trouble, ever since.[/color]
>
>I see what you mean... Money wyse, how about and SPA3102, or similar
>stuff from Gransdstream, plus an ordinary cordless phone?[/color]

Well, I started with Grandstream units... (BT488's), so going back
to an ATA might not go down well with them. There's also the law of
dininishing returns with this one - they take up more time than everyone
else combined, and I've been working with them for over a year now )-:

I need to cut down on wiring/cables, etc. in the shops - they've already
managed to set one Ethernet cable on-fire (don't ask!) Sometimes I
wonder why I bother...
[color=blue][color=green]
>>Now to wander up to the local electrical shoppie and look for 4 timers!
>>(the 3 in HQ are all on the same power strip)[/color]
>
>Good luck![/color]

Cheers,

Gordon

In article <47eda1b9.11784718@news20.forteinc.com>,
Jose <go.spam@somewhere.else> wrote:[color=blue]
>On Thu, 27 Mar 2008 12:35:07 +0000 (UTC), Gordon Henderson
><gordon+usenet@drogon.net> wrote:
>[color=green]
>> The Siemens phones
>>are the only ones that give me regular problems. (can't speak for the
>>resellers though) So I'm not going to buy any more Siemens phones (of
>>any type) until I get a resolution on this issue.[/color]
>
>Smart choice: time really is money, and more things than money can
>buy.
>
>I'd sell you Gransdtreams FXO + FXS ATAs, and reliable cordless
>phones, if I had a business near you ;-)[/color]

What is your business? Reply in email if you like ...
(Although I have a good reseller deal with at least one UK voip bits
supplier...)

Gordon

Gordon Henderson wrote:[color=blue][color=green]
>> If this happens regularly with registrations to an Asterisk-based
>> server, probably the setup is incorrect.[/color]
>
> I really don't think it is.[/color]
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...
[color=blue][color=green]
>> 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. [/color]
> 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.[/color]
How "busy" are the phones?
[color=blue]
> 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.[/color]
Can I see a trace of a failed inbound call?
[color=blue][color=green]
>> 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.[/color]
> Why?[/color]
Well, if you don't know why it's better you do it without asking, innit? ;-)
[color=blue][color=green]
>> 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.[/color]
> I run my own stun server.[/color]
How often the Siemens poll the STUN server?
[color=blue][color=green]
>> 4. Do you have - by any chance - the "qualify=yes" parameter in the
>> extension definition? Take it off.[/color]
> Why?[/color]
It's an unnecessary burden on the SIP channel and can lead to memory
leaks in the Siemens.
[color=blue][color=green]
>> 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).[/color]
> 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[/color]
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.
[color=blue][color=green]
>> 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.[/color]
> 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)[/color]
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.
[color=blue][color=green]
>> Caveat emptor: I never dealt with C450IPs, we use S450IPs. The firmware
>> and the base unit should be the same tho...[/color]
> FWIW: I make/sell/install asterisk based PBXs. I have dozens of boxes
> out there and 100's (1000's? I don't know what my resellers get up to)
> of phones connected to them, on-site and off-site. The Siemens phones
> are the only ones that give me regular problems. (can't speak for the
> resellers though) So I'm not going to buy any more Siemens phones (of
> any type) until I get a resolution on this issue.[/color]
Siemens Phones are using large chinks of FOSS code (see the full manual
appendix), if there was a problem like that I reckon the FOSS community
would have acted to fix it.
I don't dispute you know your stuff, but if you have a problem I don't
have... well, should I say more?

HTH

--
ßødincµs²°°° - The Y2K Druid
----------------------------
Law 42 on computing: Anything that could go wron@~ ¬
$: Access Violation -- Core dumped

In article <47EBAB3B.2070707@this.email>, ßødincµs <nobody@this.email> wrote:[color=blue]
>Gordon Henderson wrote:[color=green][color=darkred]
>>> If this happens regularly with registrations to an Asterisk-based
>>> server, probably the setup is incorrect.[/color]
>>
>> I really don't think it is.[/color]
>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...[/color]

Indeed - but I have C460IP's and you have S450IPs... To quote one
supplier, S = Superior, C = Cheap...
[color=blue][color=green][color=darkred]
>>> 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.[/color]
>> 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.[/color]
>How "busy" are the phones?[/color]

These are charity shops selling to people on low incomes. They are
taking 20-30 calls an hour when it's busy. They want to be able to call
the other shops & HQ to check their stock when a customer comes in
looking for something.
[color=blue][color=green]
>> 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.[/color]
>Can I see a trace of a failed inbound call?[/color]

When they next break, I'll see if I can get one.
[color=blue][color=green][color=darkred]
>>> 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.[/color]
>> Why?[/color][/color]
[color=blue]
>Well, if you don't know why it's better you do it without asking, innit? ;-)[/color]

No, I rarely do things without asking. (and I do know how DHCP works and
how to allocate ranges in my routers - I was asking why I should move
to a static IP address) If the phone behaves differntly under DHCP to
static IP addresses then there is something wrong with the phone. FWIW:
My unit at home has a static IP address and I've had it do the same thing.
[color=blue][color=green][color=darkred]
>>> 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.[/color]
>> I run my own stun server.[/color]
>How often the Siemens poll the STUN server?[/color]

The ones in the same LAN as the PBX ... Never because they don't use STUN
becasse they are on the same LAN. STUN, NAT, Networking, etc. does not
seem to be a factor.
[color=blue][color=green][color=darkred]
>>> 4. Do you have - by any chance - the "qualify=yes" parameter in the
>>> extension definition? Take it off.[/color]
>> Why?[/color]
>It's an unnecessary burden on the SIP channel and can lead to memory
>leaks in the Siemens.[/color]

So it's a bug in the Siemens then.... The other phones & ATAs connected
seem to be just fine with this - Grandstream, Snom, Nokia, Linksys, etc.
[color=blue][color=green][color=darkred]
>>> 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).[/color]
>> 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[/color]
>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.[/color]

Again, indicating a bug in the Simens units.

This particular one is fairly well documented and it doesn't appear to
be a bug, just a missing feature.

Eg.

[url]http://www.mail-archive.com/asterisk-users@lists.digium.com/msg189255.html[/url]
[color=blue]
>I don't dispute you know your stuff, but if you have a problem I don't
>have... well, should I say more?[/color]

I also have hardware you don't have, so it might just be that Siemens
have fixed the issues in the S450IP's and not bothered with their cheaper
C460IP's ... It would really surprise me if the software and hardware
in the S450's was identical to that on the C460's.

The bottom-line is that I won't be buying any more Siemens units (of
any model or type) until I get these ones fixed. Meanwhile I'll switch
to Snoms, or ATAs & Cheap analogue ones for new customers, and maybe
this one, if daily rebooting doesn't help.

Cheers,

Gordon

ßødincµs wrote:[color=blue]
> Gordon Henderson wrote:[color=green][color=darkred]
>>> If this happens regularly with registrations to an Asterisk-based
>>> server, probably the setup is incorrect.[/color]
>>
>> I really don't think it is.[/color]
> 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...
>[color=green][color=darkred]
>>> 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.[/color]
>> 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.[/color][/color]

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.
[color=blue]
> How "busy" are the phones?
>[color=green]
>> 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.[/color]
> Can I see a trace of a failed inbound call?[/color]

Me too! Or a trace of when an outbound call is attempted...
[color=blue]
>[color=green][color=darkred]
>>> 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.[/color]
>> Why?[/color]
> Well, if you don't know why it's better you do it without asking, innit?
> ;-)[/color]

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.
[color=blue]
>[color=green][color=darkred]
>>> 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.[/color]
>> I run my own stun server.[/color]
> How often the Siemens poll the STUN server?[/color]

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.
[color=blue]
>[color=green][color=darkred]
>>> 4. Do you have - by any chance - the "qualify=yes" parameter in the
>>> extension definition? Take it off.[/color]
>> Why?[/color]
> It's an unnecessary burden on the SIP channel and can lead to memory
> leaks in the Siemens.[/color]

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.
[color=blue]
>[color=green][color=darkred]
>>> 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).[/color]
>> 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[/color]
> 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.
>[/color]

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?
[color=blue][color=green][color=darkred]
>>> 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.[/color]
>> 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)[/color]
> 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.
>[color=green][color=darkred]
>>> Caveat emptor: I never dealt with C450IPs, we use S450IPs. The
>>> firmware and the base unit should be the same tho...[/color][/color][/color]

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

cheers,
Paul.

On Thu, 27 Mar 2008 13:56:24 +0000 (UTC), Gordon Henderson
<gordon+usenet@drogon.net> wrote:
[color=blue][color=green][color=darkred]
>>>I'd sell you Gransdtreams FXO + FXS ATAs, and reliable cordless[/color]
>>phones, if I had a business near you ;-)[/color]
>
>What is your business? Reply in email if you like ...
>(Although I have a good reseller deal with at least one UK voip bits
>supplier...)[/color]


I'm "only" a translator ;-) who happens to know more about Voip than
my hardware supplier - the national importer of Linksys here did not
have the SPA3102, untill I told my supplier/friend about it, and he
was told the damn thing was pretty hard to setup LOL

Tomorrow I'll start translating a software UI for a big name in IP
networks/communication integration :-))


Good luck,
Jose