Codecproblem ATA 286 und Sipgate

rsl

Aktives Mitglied
Mitglied seit
27 Mai 2004
Beiträge
1,027
Punkte für Reaktionen
0
Punkte
0
Moin,

Ich habe einen ATA 286 der mit Factoryreset, Update usw. nicht
dazu zu bewegen ist die Verbindung mit schmalbandigen Codecs
aufzubauen. Wenn er mit den passenden Codecs angerufen wird ist
alles fein, packe ich einen SipSnip- Account rein ist auch
alles ok.

Ich habe den Rufaufbau mit Sipgate bei den verschiedensten Codec-
Kombinationen gesnifft und habe nun folgende Vermutung:

Egal was ich einstelle, nur iLBC, nur G729, ein beliebiges Gemisch
der schmalbandingen Codecs, der ATA gibt im Invite immer noch den
PCMU mit raus und Sipgate hakt umgehend darauf ein ohne auch nur
einen Ansatz davon zu zeigen die Reihenfolge zu verwerten.

Ich habe die folgende Vermutung: Normal kann man dem ATA286 7
Codecs in der Reihenfolge vorgeben. Es gab allerdings mal die
Firmware 1.0.4.63 mit 8 Vorgabefeldern. Wahrscheinlich wurde
die mal auf dem ATA benutzt und hatte den PCMu als 8. Codec
drin.

Mit den Folgeversionen kann das Feld nicht mehr bearbeitet
werden weil sie wieder nur 7 Codecs in der Reihenfolge definieren
koennen.

Von einer 1.0.5.x- Version kommt man nicht mehr retour um das Feld
auf einen schmalbandigen Codec zu aendern.

Wie bekomme ich den PCMU nun wieder da raus? Hat schon mal jemand
GSconfigure- Dateien von Hand manipuliert ohne den ATA zu plaetten?

Wenn meine Vermutungen richtig sind ist die GS- Firmware in sofern
buggy da sie den Parameter mitschleppt obwohl man ihn nicht mehr
aendern kann. Ausserdem ist das Codec- Handling bei Sipgate sagen
wir mal "fragwuerdig".

Oder bin ich auf dem Holzweg?

Ruediger
 

rsl

Aktives Mitglied
Mitglied seit
27 Mai 2004
Beiträge
1,027
Punkte für Reaktionen
0
Punkte
0
Zwei Traces mit Vergleich der SW- Versionen des ATA

Ich habe jetzt noch mal einen ATA mit FW 1.0.4.68 gegengecheckt.

Hier ein Ausschnitt aus dem Trace mit FW 1.0.5.10, im ATA ist
eingestellt G723, G723, G729, G729, iLBC, iLBC, G726-32

----------------------------------------------------------
Die Anforderung der Verbindung durch den ATA:
INVITE sip:[email protected] SIP/2.0
User-Agent: Grandstream HT286 1.0.5.10
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:98 iLBC/8000
a=fmtp:98 mode=20
a=rtpmap:2 G726-32/8000
rtpmap:0 PCMU/8000
a=ptime:60

Die Antwort von Sipgate:
SIP/2.0 200 OK
User-Agent: Asterisk PBX
a=rtpmap:0 PCMU/8000
a=rtpmap:98 iLBC/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=silenceSupp:eek:ff - - - -

----------------------------------------------------------
Und nun das selbe mit 1.0.4.68, eingestellt ist
G723, G723, G729, G729, iLBC, iLBC, G726-32, 726-32

----------------------------------------------------------
INVITE sip:[email protected] SIP/2.0
User-Agent: Grandstream HT286 1.0.4.68
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:98 iLBC/8000
a=fmtp:98 mode=20
a=rtpmap:2 G726-32/8000
a=ptime:60

Die Antwort von Sipgate:
SIP/2.0 200 OK
User-Agent: Asterisk PBX
a=rtpmap:98 iLBC/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=silenceSupp:eek:ff - - - -
----------------------------------------------------------

Man sieht also dass sich Sipgate nicht mit der angeforderten Codec-
Rangfolge anfreundet sondern PCMU verwendet wenn die Gegenstelle
das ueberhaupt akzeptiert.

Man sieht auch dass der ATA ab SW 5.x immer den PCMU mitgibt obwohl er
nirgens eingestellt ist.

Durch dieses Problem kann man mit ATA ab SW 5.x keine schmalbandigen
Verbindungen mehr fahren. Das ist unmoeglich fuer ISDN- Einwahl und
suboptimal fuer Leute mit breitbandigem Anschluss die parallel
Bandbreite fuer andere Anwendungen brauchen oder auch einen
Volumentarif haben.

Kann das jemand bestaetigen? Widerlegen?

Etwas frustriert.... Ruediger
 

Robinson

Aktives Mitglied
Mitglied seit
24 Mrz 2004
Beiträge
1,751
Punkte für Reaktionen
0
Punkte
0
Hmm, dann ist wohl nur die 68er voll funktionsfähig. Bis dahin gab es auch das Problem, dass eingehend immer G711 genutzt wurde. Eine entsprechende Änderung steht im Changelog.

Trotzdem sollte Sipgate die _erste_ Übereinstimmung akzeptieren, und das wäre bei der 5.10er Version immernoch G729, max. iLBC.

Mal Sipgate und Grandstream zu dem Thema (und mit Deinen Daten) angeschrieben?
 

rsl

Aktives Mitglied
Mitglied seit
27 Mai 2004
Beiträge
1,027
Punkte für Reaktionen
0
Punkte
0
Moin,

Ich habe mir jetzt einen ATA 486 gegriffen, werksneu SW 1.0.5.10,
kein Update, kein Reset gemacht, nur die Benutzerdaten rein.

Ohne eine Aenderung unterhalten sich der ATA mit Sipgate wie folgt:
Einstellung ATA: PCMU, PCMA, G723, G729, G726, G728, iLBC
Geschickt wird PCMU, PCMA, G723, G729, G726, G728, iLBC
Sipgates Antwort: PCMA, PCMU, iLBC, G729, G726

Nun bauen wir die Schmalband- Konfig ein. Das Ding macht den selben Unfug.
Einstellung ATA: G723, G729, iLBC, G723, G729, iLBC G726.
Geschickt wird als Anforderung G723, G729, iLBC, G726, PCMU <=== ?
Sipgate antwortet PCMU, iLBC, G729, G726

Ankommend habe ich mir auch mal angesehen:
Einstellung ATA: G723, G729, iLBC, G723, G729, iLBC G726.
Sipgate schickt PCMA, PSMU, GSM, L16, iLBC, G729, DIV4
Der ATA antwortet mit PCMU

Wahrscheinlich gehe ich jetzt mal den boesen Weg, ich bestelle ein paar
Handvoll ATA bei Sipgate und lasse sie wegen des Mangels zurueckgehen,
vielleicht wacht ja mal jemand auf. Da machen beide Mist, sowohl GS als
auch SG, nur dass SG der Verkaeufer ist und damit die A- Karte hat.

rsl
 

betateilchen

Grandstream-Guru
Mitglied seit
30 Jun 2004
Beiträge
12,882
Punkte für Reaktionen
0
Punkte
0
Von einer 1.0.5.x- Version kommt man nicht mehr retour um das Feld
auf einen schmalbandigen Codec zu aendern.
Wieso nicht ? Du kannst jede beliebige ältere Version aufspielen.

Übrigens - wenn Du die gleichen Versuche mit einem Asterisk-Server unternimmst, dann wirst Du feststellen, daß die Grandstream-Geräte sich absolut KORREKT beim Aushandeln des zu verwendenden Codecs verhalten - wenn man mal davon absieht, daß der Asterisk die REIHENFOLGE der Codec-Wertigkeit AUSSCHLIESSLICH in der [GLOBAL] Sektion berücksichtig und bei allen späteren Codec ALLOWs oder DISALLOWs nach einer FESTEN Reihenfolge vorgeht.

Vielleicht haben die VoIP-Provider ähnliche Probleme mit der Codec-REIHENFOLGE
 

rsl

Aktives Mitglied
Mitglied seit
27 Mai 2004
Beiträge
1,027
Punkte für Reaktionen
0
Punkte
0
Moin,

Klar kann man auf eine 4.x zurueck, die haben aber auch ihre
Macken. Das Fehlerbild ist inzwischen etwas anders. Meine
erste Vermutung war, dass der 8. Codec in der Reihenfolge
irgendwann mit einer 4.x SW im ATA gelandet ist und mit folgenden
Versionen nicht mehr veraenderbar ist. (mein erstes Posting)

Jetzt habe ich das mit einem werksneuen ATA486 ueberprueft, bei
dem kann man wohl ausschliessen dass er aeltere SW- Versionen
drin hatte. Das Fehlerbild ist das selbe. Die Kiste bietet dem
Provider einen Codec an der nirgens eingestellt ist.

Fuer mich ist es ein Bug in der Firmware das ATA. Das muss GS
reparieren, schliesslich liefern sie ab Werk 1.0.5.10. Die
Reparatur kann nicht SW 1.0.4.68 heissen.

Zu der Codecreihenfolge bei den SIP- Providern, ja da kann man
alles moegliche erleben, ich habe aber im Moment keine Lust den
Muellhaufen aufzubuddeln.

rsl
 

Enno

Neuer User
Mitglied seit
22 Jun 2004
Beiträge
3
Punkte für Reaktionen
0
Punkte
0
Hi,

die Verwendung von G.711 ist kein Bug, sondern ein Feature. Ich habe dazu Grandstream angeschrieben und folgende Antworten zurückerhalten:

Hi, Enno,
PCMU is our default codec in case that the other party can't work with
the codec you specified. You can see the actual codec that both party agree
in 200 ok message. Thanks.
Auf meine weitere Nachfrage nach dem Sinn dieser Erweiterung schreibt Grandstream dann:


We introduce PCMU/A as default codec since it is very useful when you
use Fax-over-IP function. PCMU/A will be chosen in the fax-detection
scenario.
Ich verstehe nach wie vor nicht, was das soll. Vielleicht wird Grandstream diese Änderung ja zurücknehmen oder zumindest abschaltbar machen, wenn nur genügend Nutzer sich beschweren.

Gruß,

Enno
 

rsl

Aktives Mitglied
Mitglied seit
27 Mai 2004
Beiträge
1,027
Punkte für Reaktionen
0
Punkte
0
Ich habe auf meine Frage gar keine Antwort bekommen.

Wenn das Feature so toll ist sollte es irgendwo dokumentiert sein.

Es bleibt die Frage warum die Codecs ueberhaupt konfigurierbar sind.

rsl
 

garnixan

Neuer User
Mitglied seit
22 Aug 2004
Beiträge
153
Punkte für Reaktionen
0
Punkte
0
Hallo,

ich habe auch mal probiert schmalbandige Verbindungen via Sipgate ins Festnetz mit dem BT-101 aufzubauen. Irgendwie klang das immer wie sonst auch. Wo kann ich denn einsehen, was bei welchem Telefonat ausgehandelt wurde und welcher Codec letztlich verwendet wurde. Wenn Grandstream grundsätzlich PCMU verwendet macht die Liste der Codecs in der Tat keinen Sinn mehr!

Gruß aus Köln,


garnixan
 

spooky1980

Neuer User
Mitglied seit
14 Jun 2004
Beiträge
96
Punkte für Reaktionen
0
Punkte
0
stimmt ja gar nicht

bei meinem bt101 mit 5.10 nimmt er auch den codec, der an erster stelle steht. getestet mit pcma, 726 und ilbc.

chris
 

rsl

Aktives Mitglied
Mitglied seit
27 Mai 2004
Beiträge
1,027
Punkte für Reaktionen
0
Punkte
0
garnixan schrieb:
Wo kann ich denn einsehen, was bei welchem Telefonat ausgehandelt wurde und welcher Codec letztlich verwendet wurde.
Mit einem Sniffer auf dem LAN schauen, ich verwende Ethereal, der kann
ganz gut filtern.

garnixan schrieb:
Wenn Grandstream grundsätzlich PCMU verwendet macht die Liste der Codecs in der Tat keinen Sinn mehr!
Da hast du was falsch verstanden, die GS koennen die anderen Codecs,
dumm ist zur Zeit nur dass sie den PCMU der Gegenstelle anbieten
selbst wenn er nicht eingestellt ist. In Kombination mit Sipgate ist das
momentan toedlich weil die den bevorzugen.

rsl
 

garnixan

Neuer User
Mitglied seit
22 Aug 2004
Beiträge
153
Punkte für Reaktionen
0
Punkte
0
Hallo,

mich interessiert die Sache jetzt. Diesen Sniffer muß ich erst mal für Mac OS finden. Logfiles oder so was kann man nicht am Telefon auslesen?

Bei mir ist es egal welchen Codec ich nach oben auf die Liste setze: Die Sprachqualität ins Festznetz ist immer gleich (gut). Das ist ja eher positiy, trotzdem möchte ich der Sache auf den Grund gehen.

Gruß aus Köln,


garnixan
 

exim

Admin a.D.
Mitglied seit
27 Apr 2004
Beiträge
1,013
Punkte für Reaktionen
0
Punkte
0
Grandstream-HW liefert keine Logs. Zwischen die Verbindung GS <--> Router klemmst Du einen Hub (keinen Switch!), stöpselst einen Rechner an und lässt den Sniffer laufen. Du musst zum Sniffen nicht Ethereal einsetzen, tcpdump (sowas sollte es auf MacOS X geben) reicht völlig. Zum Auswerten der gesnifften Daten bietet sich dann Ethereal an. Dat gibts fertig für alle möglichen Betriebssysteme und wie es aussieht auch für Mac OS X: http://www.ethereal.com/download.html#otherplat

Ethereal kann mit allen möglichen Paket-Log-Proggi-Formaten umgehen, guckst Du hier http://www.ethereal.com/docs/user-guide/ChIOOpenSection.html#ChIOInputFormatsSection unter Punkt 5.2.2 "Input File Formats"
 

garnixan

Neuer User
Mitglied seit
22 Aug 2004
Beiträge
153
Punkte für Reaktionen
0
Punkte
0
Hallo exim,

vielen Dank für Deine Hilfe! Ich hatte bisher immer so 10-15 Euro Kosten für Telefonie im Monat und habe gehofft diese durch IP-Telefonie auf unter 5 Euro senken zu können. Die Anschaffung eines Hubs (habe nur einen Switch) macht den Kostenvorteil natürlich wieder zunichte. Was soll's, es macht ja auch Spaß!

Danke nochmal für die Hinweise. Mal sehen, ob ich das hinbekomme.

Gruß aus Köln,


garnixan
 

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
231,870
Beiträge
2,016,188
Mitglieder
348,966
Neuestes Mitglied
bilgehz