Discussion:
Problem: Siemens Gigaset C450 IP + Sipgate
(zu alt für eine Antwort)
m. vanselow
2006-08-04 23:28:11 UTC
Permalink
Hallo,

seit kurzem haben wir sipgate und Siemens Gigaset C450 IP.
der Anschluss verlief ohne Probleme.

Leider ist der Telefonton oft sehr abgehackt, manchmal kann einer der beiden
Teilnehmer gar nichts hören, während der andere alles problemlos hört.

wo kann das Problem liegen?
ist das bei sipgate so üblich?

Gruß
Heinrich
Dominique Görsch
2006-08-05 11:11:24 UTC
Permalink
Post by m. vanselow
Hallo,
seit kurzem haben wir sipgate und Siemens Gigaset C450 IP.
der Anschluss verlief ohne Probleme.
Leider ist der Telefonton oft sehr abgehackt, manchmal kann einer der beiden
Teilnehmer gar nichts hören, während der andere alles problemlos hört.
wo kann das Problem liegen?
ist das bei sipgate so üblich?
Es würde helfen wenn du uns mitteilst, welche Seite überwiegend die
Probleme hat. Wenn z.B. die Gegenseite oft abgehakten Klang hat, deutet
das auf einen zu geringen oder ausgelasteten Upstream hin. Natürlich
kann es auch an Sipgate liegen, üblich ist dies jedoch nicht.

Gruß
Dominique Görsch
Ingo Lembcke
2006-08-05 17:36:01 UTC
Permalink
Hallo,
Post by m. vanselow
Leider ist der Telefonton oft sehr abgehackt, manchmal kann einer der beiden
Teilnehmer gar nichts hören, während der andere alles problemlos hört.
Habe seit heute dasselbe Telefon, auch über Sipgate. Ein einziges
VoIP-Testgespräch reichte mit der passenden Software aus, um rauszufinden,
wie die Sprachqualität, die beim Partner (Festnetz) ankommt, drastisch
zu senken ist...
Es ist meistens der Upstream, der die Qualität bestimmt.
Ich habe TDSL 6000 (seit 01.08.06), vorher habe ich VoIP gar nicht
ausprobieren wollen.
Der Donkey (bzw. bei mir aMule, weil iMac) kann schnell den Upload
voll ausreizen und ist auch gut konfigurierbar, daß er eben das nicht
tut. Ich habe den während des Gesprächs gestartet, die Qualität ist
lt. Gesprächspartner deutlich gesunken, inkl. Aussetzer - ich habe
ihn aber noch gut verstanden, naja, Festnetz bis Sipgate halt. Der Upload
von aMule war auf 30 kB/s begrenzt, das ist bei TDSL 6000 etwa die
halbe, maximale Uploadgeschwindigkeit. Ich habe das dann spasseshalber
auf einen Phantasiewert (120 kByte/s) gesetzt, dann ist der Upload so um
die 60-65 kByte/s. Lt. Gesprächspartner hat er mich fast gar nicht mehr
gehört, und wenn dann nur abgehackt. Ich habe dann aMule beendet,
und die Qualtität war nach ca. 1/2 min. wieder erträglich.

Ich habe jetzt mal probeweise beim C450 IP einen anderen Codec
als bevorzugt eingestellt, mal sehen, ob das einen Unterschied macht.

Fazit: es hängt vom Anschluss ab, sowohl der Qualität, als
auch der gebuchten Geschwindigkeit. Mit TDSL 1000 und der
entsprechenden Uploadgeschwindigkeit halte ich es VoIP nicht
so sinnvoll. Und an Sipgate liegt das nicht, da haben die keinen
Einfluss drauf.

mfg,
Ingo Lembcke
Dominique Görsch
2006-08-05 18:28:12 UTC
Permalink
Post by Ingo Lembcke
Ich habe jetzt mal probeweise beim C450 IP einen anderen Codec
als bevorzugt eingestellt, mal sehen, ob das einen Unterschied macht.
Ein sparsamerer Codec verringert die Sprachqualität per Definition.
Post by Ingo Lembcke
Fazit: es hängt vom Anschluss ab, sowohl der Qualität, als
auch der gebuchten Geschwindigkeit. Mit TDSL 1000 und der
entsprechenden Uploadgeschwindigkeit halte ich es VoIP nicht
so sinnvoll. Und an Sipgate liegt das nicht, da haben die keinen
Einfluss drauf.
DSL1000 reicht für ein Gespräch aus, wenn der Upstream ansonsten
unbelastet ist. Und die Netzqualität von Sipgate hängt sehrwohl mit der
Sprachqualität zusammen, auch deren Netz und deren Server haben Lags wie
mein Monitoring zeigt. Aktuell zeigt z.B. dusnet bei mir eine Latenz von
teilweise über 500ms, nicht wirklich schön beim Telefonieren. Für mich
am schnellsten zu erreichen ist Arcor (ist auch mein ISP) mit etwa 15ms
im Schnitt.

Gruß
Dominique Görsch
Christian Schmidt
2006-08-06 10:35:19 UTC
Permalink
Post by Dominique Görsch
DSL1000 reicht für ein Gespräch aus, wenn der Upstream ansonsten
unbelastet ist. Und die Netzqualität von Sipgate hängt sehrwohl mit der
Sprachqualität zusammen, auch deren Netz und deren Server haben Lags wie
mein Monitoring zeigt. Aktuell zeigt z.B. dusnet bei mir eine Latenz von
teilweise über 500ms, nicht wirklich schön beim Telefonieren. Für mich
am schnellsten zu erreichen ist Arcor (ist auch mein ISP) mit etwa 15ms
im Schnitt.
Wie testest Du das?

Gruß

Chris
--
Jetzt auch bei mir: http://blog.superbilk.org
Dominique Görsch
2006-08-06 16:14:05 UTC
Permalink
Post by Christian Schmidt
Post by Dominique Görsch
DSL1000 reicht für ein Gespräch aus, wenn der Upstream ansonsten
unbelastet ist. Und die Netzqualität von Sipgate hängt sehrwohl mit der
Sprachqualität zusammen, auch deren Netz und deren Server haben Lags wie
mein Monitoring zeigt. Aktuell zeigt z.B. dusnet bei mir eine Latenz von
teilweise über 500ms, nicht wirklich schön beim Telefonieren. Für mich
am schnellsten zu erreichen ist Arcor (ist auch mein ISP) mit etwa 15ms
im Schnitt.
Wie testest Du das?
Mein Asterisk zeigt für alle eingetragenen Peers die Latenz an, wenn
Qualify=yes gesetzt ist.

,---
| CLI> sip show peers
| Name/username Host Dyn Nat ACL Port Status
| arcor/user 145.253.131.134 N 5060 OK (16 ms)
| webcalldirect/user 80.239.235.200 N 5060 OK (20 ms)
| simplyconnect/user 84.16.230.246 N 5060 OK (18 ms)
| dusnet/user 83.125.8.46 N 5060 OK (11 ms)
| ...
`---

Im Augenblick mit 11ms dusnet 5ms vor Arcor, ist aber selten zu sehen...

Gruß
Dominique Görsch
Werner Henze
2006-08-06 16:51:52 UTC
Permalink
Hallo!

So wie ich das verstehe, zeigt "sip show peer" die Delays zu den Registraren
an. Das ist aber im Telefonat weniger interessant. Viel interessanter ist
dann das Delay zum Angerufenen (bzw. Gateway).

Ciao,
Werner...
--
PGP 8 available
http://home.arcor.de/werner.henze
Dominique Görsch
2006-08-06 19:25:33 UTC
Permalink
Post by Werner Henze
Hallo!
So wie ich das verstehe, zeigt "sip show peer" die Delays zu den Registraren
an. Das ist aber im Telefonat weniger interessant. Viel interessanter ist
dann das Delay zum Angerufenen (bzw. Gateway).
Je nach Einstellung von "canreinvite" läuft das Gespräch aber auch über
eben diesen Registrar. Wenn es nicht darüber läuft ist die Latenz dahin
in der Tat uninteressant. Wie es die einzelnen Anbieter mit dem
canreintive Handhaben weiss ich nicht, ich persönlich lasse auch reinen
SIP-Traffic bei mir durch den Asterisk laufen.

Gruß
Dominique Görsch
Thomas Bernhard
2006-08-06 18:31:46 UTC
Permalink
Post by Dominique Görsch
Mein Asterisk zeigt für alle eingetragenen Peers die Latenz an, wenn
Qualify=yes gesetzt ist.
Das hat wenig Aussagekraft. Der Server der die qualify Anfragen bearbeitet
muss/wird nicht der Server sein der das Gespräch führt.

Qualify soll den Paketfilter bei einem NAT-Router offen halten hinter dem
ein Client steht. Bei Provider peers sollte man qualify ausschalten.
Dominique Görsch
2006-08-06 19:34:05 UTC
Permalink
Post by Thomas Bernhard
Post by Dominique Görsch
Mein Asterisk zeigt für alle eingetragenen Peers die Latenz an, wenn
Qualify=yes gesetzt ist.
Das hat wenig Aussagekraft. Der Server der die qualify Anfragen bearbeitet
muss/wird nicht der Server sein der das Gespräch führt.
Ohne das weiter debugged zu haben, aber bei vielen Anbietern wird
zumindest das PSNT-Gate die selbe Maschine oder zumindest im selben Netz
stehen, so dass es schon gewisse Aussage hat. Je nach Einstellung von
"canreinvite" läuft sogar das Gespräch durch die Infrastruktur des
Anbieters.
Post by Thomas Bernhard
Qualify soll den Paketfilter bei einem NAT-Router offen halten hinter dem
ein Client steht. Bei Provider peers sollte man qualify ausschalten.
Das ist ein Nebeneffekt der sich zur Nutze gemacht wird, der Sinn
dahinter ist eigentlich der, anhand der Latenz zu beurteilen ob ein Peer
oder Friend als online oder offline angesehen wird.

,---
| If you turn on qualify in the configuration of a SIP device in
| sip.conf, Asterisk will send a SIP OPTIONS command regularly to check
| that the device is still online. If the device does not answer within
| the configured (or default) period (in ms) Asterisk considers the
| device off-line for future calls.
`--- (von http://www.voip-info.org/wiki-Asterisk+sip+qualify)

Gruß
Dominique Görsch
Thomas Bernhard
2006-08-07 21:08:06 UTC
Permalink
Post by Dominique Görsch
,---
| If you turn on qualify in the configuration of a SIP device in
| sip.conf, Asterisk will send a SIP OPTIONS command regularly to check
| that the device is still online. If the device does not answer within
| the configured (or default) period (in ms) Asterisk considers the
| device off-line for future calls.
`--- (von http://www.voip-info.org/wiki-Asterisk+sip+qualify)
Das könnte mal aktualisiert werden. Ob ein Anruf durchgeht und welche
Qualität das Gespräch hat kannst Du nur feststellen wenn Du den Anruf
durchführst.

Nimm zwei Accounts bei einem peer, stell einen auf qualify=yes und wenn
Asterisk das peer offline meldet führe ein Gespräch über den anderen
Account. Du wirst sehen, dass Gespräch ist erfolgreich.

Durch qualify=yes schaltest Du peers unnötig offline.

Dazu kommt noch das qualify bei Realtime gar nicht oder nur schlecht
funktioniert. Spätestens dann kannst Du es nicht mehr benutzen. Das ist
aber auch nicht wirklich ein Problem.
Sven Geggus
2006-08-06 19:22:53 UTC
Permalink
Post by Dominique Görsch
Ein sparsamerer Codec verringert die Sprachqualität per Definition.
Der OP redet con Sipgate. Sipgate unterstützt leider den GSM Codec
nicht.

Sven
--
"We just typed make"
(Stephen Lambrigh, Director of Server Product Marketing at Informix
about porting their Database to Linux)
/me is ***@ircnet, http://sven.gegg.us/ on the Web
Ruediger Schwarz-Linek
2006-08-07 16:27:56 UTC
Permalink
Sven Geggus schrieb
Post by Sven Geggus
Post by Dominique Görsch
Ein sparsamerer Codec verringert die Sprachqualität per Definition.
Der OP redet con Sipgate. Sipgate unterstützt leider den GSM Codec
nicht.
Wie kommst du darauf? Hier geht es auch mit GSM. Sowohl Testnummer,
als auch Anruf ins Festnetz als auch Voicemail.

Ruediger
Sven Geggus
2006-08-09 20:00:45 UTC
Permalink
Post by Ruediger Schwarz-Linek
Wie kommst du darauf? Hier geht es auch mit GSM. Sowohl Testnummer,
als auch Anruf ins Festnetz als auch Voicemail.
hm, ich hab im sip.conf für sipgate sowas drin:
disallow=all
allow=gsm
allow=g726
allow=alaw
allow=ulaw

Trotzdem wird alaw verwendet:
Peer User/ANR Call ID Seq (Tx/Rx) Form Hold Last Message
217.10.79.9 10000 358a6ddf4d4 00103/00000 alaw No Tx: ACK

So komm ich da drauf.

Sven
--
/* Fuck me gently with a chainsaw... */
(David S. Miller in /usr/src/linux/arch/sparc/kernel/ptrace.c)

/me is ***@ircnet, http://sven.gegg.us/ on the Web
Loading...