2002L: "Leerlauf"-Bandbreite wird immer weniger

[pvr]

Hallo,

ich meine, bei mir folgendes Problem festgestellt zu haben.

Ich messe per speedtest.nl vor dem Telefonieren, die verfügbare Bandbreite durch, da wir nur DSL 1000 haben.
Nun ist es mir schon öfter vorgekommen, dass 127 kbit/s Upload verfügbar waren. Nach dem Telefonat messe ich jedesmal eine geringere Bandbreite, gerade eben z.B. 2 Mal gewählt, aber Teilnehmer nicht erreicht.
Vor dem Wählen 127 kbps, danach 69 kbps.

Ab- und Anmelden bei Sparvoip ändert daran nichts, wenn ich den ATA aber neu starte, dann messe ich danach wieder die 127 kbps.
Am Sparvoip liegt's also eher nicht, denke ich.

Firmware-Version: V3.60(ML.1) | 08/16/2005

Hat jemand zufällig die gleichen Erfahrungen?

Viele Grüße
ANdreas

 

[ciesla]

Probier's mal mit neuer Firmware, z.B. MH3 oder MH4.
Wie das geht, ist auch hier im Forum beschrieben.

 

[pvr]

Tja, würde ich ja gerne, aber bisher ist's am Kabel gescheitert. :-(

Allerdings ein Update:
Ich habe gerade mal ein bisschen mit dem telnet-Zugang herumgespielt und folgendes festgestellt.

Wenn ich anrufe, niemand abnimmt und ich wieder auflege, bleiben rtp(?)-Verbindungen bestehen.

Ohne Anruf, bzw. nach erfolgreichem Anruf:

P2002L> voice fsm status rtp
No active port exist now!

Während dem Klingeln:

P2002L> voice fsm status rtp
***********************************************
Port origin_chId : 0
Port chId : 2000
Payload Type : 18
Dest IP : 194.221.62.171
Dest Port : 25374
Source Port : 50004
SSRC : 0x25f2af1d
flaghs: 0x0
transmit packet count : 271
transmit octet count : 7880
transmit cumulative lost packet count : 0
receive packet count : 383
receive octet count : 7660
RTCP receive count : 0
RTCP transmit count : 3608
RTCP transmit fail count : 0
voipRtpCallBack = 80201eb0
Cname : ZyTalk_Port2000
Receiver SSRC :0x02ff0f77


Und nach dem Auflegen geht es munter weiter:

P2002L> voice fsm status rtp
***********************************************
Port origin_chId : 0
Port chId : 2000
Payload Type : 18
Dest IP : 194.221.62.171
Dest Port : 25374
Source Port : 50004
SSRC : 0x25f2af1d
flaghs: 0x0
transmit packet count : 152
transmit octet count : 4624
transmit cumulative lost packet count : 0
receive packet count : 182
receive octet count : 3640
RTCP receive count : 0
RTCP transmit count : 94
RTCP transmit fail count : 0
voipRtpCallBack = 80201eb0
Cname : ZyTalk_Port2000
Receiver SSRC :0x02ff0f77

Auch ein Trennen der Verbindung nutzt nichts.

Wenn ich allerdings den lokalen SIP-Port abändere (wodurch ja zwangsweise ein Reconnect stattfindet), dann geht die Connection endlich zu.

Besondere Einstellungen habe ich eigentlich nicht.
Da nicht jeder das Problem zu haben scheint, vielleicht ist es aber doch ein Konfig-Fehler oder liegt am Zusammenspiel Zyxel/Sparvoip?

Anbei mal meine Konfig, vielleicht findet sich ja jemand, der es mal mit seinen Daten vergleichen kann.
"Besonderheiten" sind aber eigentlich nur: kein STUN-Server + "Registartion Expiration Time = 3600", weil's bei AOL per Default auf 180 steht und sich daher alle 90 Sekunden reregistriert. Hm, da steht wirklich "Registartion" und nicht "Registration"... Ob's daran liegt? ;-)

980101001 = SIP #1 Active <0(No) | 1(Yes)> = 1
980101002 = SIP #1 Server Address = sip.sparvoip.de
980101003 = SIP #1 Server Port <1024~65535> = 5060
980101004 = SIP #1 Registartion Server IP = sip.sparvoip.de
980101005 = SIP #1 Registartion Server Port <1024~65535> = 5060
980101006 = SIP #1 Registartion Expiration Time <2~65535> = 3600
980101007 = SIP #1 Register ReSend Time <1~65535> = 180
980101008 = SIP #1 Session Expire Time <30~3600> = 180
980101009 = SIP #1 Local signaling Port <1024~65535> = 5070
980101010 = SIP #1 RTP Port Range Start <1024~65535> = 50000
980101011 = SIP #1 RTP Port Range End <1024~65535> = 65535
980101012 = SIP #1 UserId = meine Sparvoip-ID
980101013 = SIP #1 Password = ********
980101014 = SIP #1 Phone Number = 00496969xxxxxx
980101015 = SIP #1 Minimun Session Expire Time <20~1800> = 180
980101016 = SIP #1 Retransmit T2 = 4
980101017 = SIP #1 Domain Name = sparvoip.de
980101018 = SIP #1 Mapping to POTS Phone1 <0(No) | 1(Yes)> = 1
980101019 = SIP #1 Mapping to POTS Phone2 <0(No) | 1(Yes)> = 1
980101020 = SIP #1 CODEC Type 1 <0(G711mu) |8(G711A) |18(G729)> = 18
980101021 = SIP #1 CODEC Type 2 <0(G711mu) |8(G711A) |18(G729)> = 8
980101022 = SIP #1 DTMF Key Type <0(RFC_2833) |1(PCM)|2(SIP_INFO)|3(RFC_2833_LIKE_SIP_INFO)> = 2
980101023 = SIP #1 Transport Type <0(UDP) |1(TCP)> = 0
980101024 = SIP #1 Hide Caller ID <0(No) |1(Yes)> = 0
980101025 = SIP #1 Auto Redial <0(No) |1(Yes)> = 0
980101026 = SIP #1 STUN Server Active <0(No) | 1(Yes)> = 0
980101027 = SIP #1 STUN Server Address = No)
980101028 = SIP #1 STUN Server Port <1024~65535> = 3478

 

[VeronaFeldbusch]

Hallo,

das Kabel könnte ich dir leiweise zur verfügung stellen.

Gruß Verona

 

[pvr]

das Kabel könnte ich dir leiweise zur verfügung stellen.

Hi Verona,

ok danke (jetzt muss ich mir ne andere Ausrede einfallen lassen ;-) ).
Ich komme vielleicht drauf zurück, aber wenn du nicht gerade in Darmstadt wohnst, dann düfte sich ein Hin- und Herschicken nicht lohnen. Denke, wenn ich mich näher damit befasse, dann kriege ich das Kabel schon woher. Irgendwie scheue ich mich nur immer auch ein bisschen vor "Hardware-Eingriffen" - zumal nicht gesagt ist, dass es was ändert.

Aber noch was anderes.
Ich habe gestern noch einen Work-Around für mein Problem gefunden.

Wie hier beschrieben, habe ich RTCP deaktiviert.

Meine komischen verbindungen bleiben zwar nun immer noch bestehen, aber sie verbrauchen kaum mehr Bandbreite.

Wäre natürlich genial, wenn mir jemand weiterhelfen könnte, wie ich die Verbindungen korrekt terminiere.

Viele Grüße
Andreas