Mögliche Ursache für die 2-Tages-Abstürze der Firmware und hoher Batterieverbrauch

[woprr]

http://www.ip-phone-forum.de/showpost.php?p=953305&postcount=7

da das problem hier viele haben, mal extra thread.

wer das pirelli an asterisk hat, soll qualify=no setzen, schreibt einer auf voip-info.org.

hab das vor 3 tagen mit meinem CallWeaver gemacht, und siehe da, der Akku hält auffallend länger und das 2-Tage-Absturz-/Einfrier-/SIP-störungsproblem scheint weg zu sein, leute die das problem mit dem pirelli an ihrem SIP-provider haben, sollten mal mit nem netzwerksniffer nachsehen, allerdings denke ich nicht, dass die provider auf die paar Wifi/SIP-handys die es gibt da rücksicht nehmen werden, wenn das das problem ist...

pirelli muss da ne lösung finden in der firmware, wenn sich das bestätigt.

 

[betateilchen]

Ich denke auch, daß das über die Firmware geklärt werden müßte. Das Problem mit den SIP Notify für das qualify haben viele andere Geräte übrigens auch.

Nun das große ABER:

Es gibt nur eine sehr geringe Anzahl von VoIP Providern, die wirklich mit einem Asterisk als Frontend arbeiten und die Messages für das qualify überhaupt an das Endgerät verschicken. Die meisten Provider arbeiten mit anderen Frontends (SER etc) und da gibt es solche Datenpakete gar nicht.

Eventuell wäre interessant zu erfassen, bei welchen Providern das Problem auftritt. Und dann mal gegenüberstellen, was dort als Frontend läuft.

Tatsache ist natürlich, daß das qualify die Akkulaufzeit verringert, da die NOTIFY regelmäßig beantwortet werden müssen. Dazu muß natürlich der WLAN Teil komplett aktiviert werden.

 

[woprr]

volle zustimmung. hmm als ich Ekiga noch direkt an sipgate hatte kam mal als ID "Sipgate Asterisk" bei unbekannten Anrufern mit, das wär dann schonmal einer, wenn qualify an (auf der eigenen userseite wird der gerätestatus angezeigt, aber kann ja auch anders erfasst werden).
achja, und in meinem CallWeaver/Sinus TC300 bastelthread unten hab ich glaub ich auch geschrieben, dass das pirelli mit qualify=yes total gesponnen hat, hab dann 5000 gesetzt, die "ping"zeiten von bis/über 500ms bei sip show peers fürs pirelli haben mich auch immer stutzig gemacht (wohl die powersave wakeupzeit der chips).

 

[betateilchen]

Es wäre mir neu, daß bei Sipgate ein Asterisk als Frontend läuft Damit wäre z.B. der Parallelruf nicht möglich.

 

[woprr]

das hab ich auch nicht gesagt, nur dass das als ID kam und ne vermutung. allerdings möglich dass sipgate entwickler einen eigenen fork von asterisk gemacht haben dass massenprovider eher nicht * benutzen hab ich auch mal stellenweise gelesen, keine ahnung, ich bin ja als automatisierer ned in dem geschäft.

 

[woprr]

ohjee nee, ohne qualify isses noch schlimmer:

Dec 20 13:58:43 VERBOSE[3040914320] logger.c: -- Executing Dial("SIP/xxxxxxx-2c05", SIP/201&SIP/210&SIP/211&SIP/212,20,w)
Dec 20 13:58:43 VERBOSE[3040914320] logger.c: -- Called 201
Dec 20 13:58:43 VERBOSE[3040914320] logger.c: -- Called 210
Dec 20 13:58:43 NOTICE[3040914320] app_dial.c: Unable to create channel of type 'SIP' (cause 3 - No route to destination)
Dec 20 13:58:43 NOTICE[3040914320] app_dial.c: Unable to create channel of type 'SIP' (cause 3 - No route to destination)
Dec 20 13:58:43 VERBOSE[3040914320] logger.c: -- SIP/210-9525 is ringing
Dec 20 13:58:51 VERBOSE[3040914320] logger.c: -- SIP/210-9525 answered SIP/5604212-2c05

201 is das pirelli (tc300), ohne qualify scheints mit der zeit ganz wegzupennen, wlan/sip status anzeige aber ok, das gibts doch ned

nee dann setz ich wieder qualify=5000 da krieg ich wenigstens ne anzeige bei pirelli SIP störung.

ausserdem ist das pirelli trotzdem aktiv, es sendet jede minute 4bytes ans PBX, "CRLF refresh":

xxxx:~# tcpdump -vvv -s0 -i eth2 src or dst host pir.tc300.net
tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes


14:14:49.028279 IP (tos 0xe0, ttl 127, id 44, offset 0, flags [none], proto: UDP (17), length: 32) pir.tc300.net.sip > 192.168.100.2.sip: [udp sum ok] SIP, length: 4



0x0000: 0d0a 0d0a
14:15:49.111512 IP (tos 0xe0, ttl 127, id 45, offset 0, flags [none], proto: UDP (17), length: 32) pir.tc300.net.sip > 192.168.100.2.sip: [udp sum ok] SIP, length: 4



0x0000: 0d0a 0d0a

ich versuch mal den verkehr zwischen dem pirelli und der sinus tc 300 zu scannen (PBX bypass), vielleicht lässt sich da was ersehen wie das pirelli es gern hätte...