Falsche Codecverhandlung?

[Xday]

Hallo,
meine Freundin nutzt das Freenet iPhone. Mit der mitgelieferten Software funktioniert alles wunderbar, aber leider ist die Rauschreduktion etwas zu stark. Bei Telefonaten hat man immer das Gefühl der Gesprächspartner hätte aufgelegt, wenn er nichts sagt. Deswegen und wegen ein paar anderen Macken wollten wir nun X-Lite 3.0 probieren.

Die Software ist eigentlich super, abgehende Telefonate laufen perfekt. Eingehende Telefonate werden zwar korrekt signalisiert und sie kann den Anrufer auch verstehen. Der Anrufer hört aber niemanden.

Nachdem ich alle möglichen Routereinstellungen probiert und den PC sogar an einem anderen Internetanschluß getestet habe, hab ich mit Wireshark mal die Daten mitgeloggt.
Die RTP Pakete kommen auch an wenn sie angerufen wird, aber die von Wireshark angezeigte Codierung (PCMU) unterscheidet sich von der Codierung der gesendeten Pakete (PCMA).
Bei der von ihr angestoßenen Verbindung, bei der sich beide Parteien verstehen, ist die Kodierung der empfangenen und gesendeten Pakete gleich (PCMA).

Handelt X-Lite die Verbindungsdaten nun falsch aus oder liegt der Fehler irgendwo anders?

 

[spongebob]

A und u ("mü") sind prinzipiell identisch. Im Grund ist es in beiden Fällen ein Verfahren zur Minimierung des sog. Quantisierungsrauschens, welches sich zwangsläufig einstellt, wenn alle Amplitudenstufen gleichwertig digitalisiert werden würden. Deswegen quantisiert man die niedrigen Amplitudenstufen in mehr Stufen (=Digitalwerten), als höhere (=lautere) Amplitudenwerte.

Die dabei verwendete nichtlineare Kennline ist einfach unterschiedlich in beiden Verfahren. Die Wandlung von A nach PCM bzw. u nach PCM und zurück (PCM = 16 bit) ist i.d.R. ein simples, (fast) verlustfreies Table-Lookup.

Es kann eigentlich nicht daran liegen.

UPDATE: Lese gerade noch mal Dein Posting: Es geht, wenn beide auf A fahren... In diesem Falle macht einfach eine der beteiligten Parteien bei der Dekodierung einen Fehler. Prinzipiell sollte eine Asymmetrie hier kein Problem sein.

UPDATE UPDATE: Codec wird auch nicht wirklich verhandelt. Beide Parteien deklarieren im SDP ihren favorisierten Codec, das wars.

Wenn Du eine FB hast, so trace das Gespräch doch mal hiermit mit:
http://www.ip-phone-forum.de/showthread.php?t=129725

Da kannst Du das Audio auch gleich extrahieren, wenn es drin ist.

Grüsse

 

[Xday]

Eine FB habe ich nicht, aber den Traffic habe ich ja auch schon mitgeschnitten.

Ich habe jetzt gesehen, dass man bei Wireshark ja auch die Audiostreams direkt anhören kann. Also abgehende Stream ist in Ordnung.

Das Problem ist dann also der Freenet Server, der die empfangenen Streams nicht richtig decodiert? Ich rufe ja von einem Festnetzanschluß an.

 

[spongebob]

Das kann man nur beurteilen, wenn man die Daten sieht....Kannst mir den Trace ja mal mailen. [email protected]

Grüsse

 

[Xday]

Danke nochmal für die Auswertung.

Ich habe meine Problem jetzt mal dem Counterpath support berichtet.

http://support.counterpath.com/viewtopic.php?t=9731

Das Problem läßt sich folgendermaßen beheben:

Dial ***7469 (SEND)
This will bring up the advanced settings window
Filter for honor
Double click on the honor entry and change the value to 1


X-Lite sendet die Daten jetzt im richtigen Format, aber jetzt sendet es die Stimme des Anrufers auch wieder raus. Der Anrufer hört sich also nur selber. Bis jetzt habe ich das Problem noch nicht gefunden....

 

[spongebob]

In Ergängzung zu obigem Posting: Es hat sich herausgestellt, dass das XLite bei einkommenden Gesprächen fälschlicherweise ausgehende Daten ulaw kodierte, obwohl in der SIP/SDP Negotiation beidseitig Alaw vereinbart wurde. Dies hat die Gegenstelle berechtigt als Silence "zu Gehör" gebracht.

Das "neue" Problem ist ein altes. Ich habe es schon in Deinen Alaw Traces gehört. Es ist ein ziemliches Echo drauf. Grund dafür könnte die schlechte oder fehlende Echokompensation des Xlites sein.

Grüsse

 

[Xday]

Persönlich halte ich das Signal nicht für ein Echo, denn X-Lite sendet wirklich NUR meine Sprache wieder raus. In den Aufzeichnungen sieht man keine 2. Stimme, die Sprache des X-Lite Users wird also ignoriert.

Morgen ist der PC wieder neben mir, dann werde ich das nochmal ausführlich testen.

 

[spongebob]

Ach so, dann hatte ich das falsch verstanden. Kannst ja noch mal tracen...

Grüsse

 

[Xday]

Die Probleme sind inzwischen behoben.

Das Codeproblem konnte durch die Einstellung im erweiterten Menü von X-Lite gelöst werden.
Natürlich musste dann auch gleichzeitig die Soundkarte den Geist aufgeben, deshalb das seltsame Echo-Verhalten. Mit neuer Soundkarte funktioniert jetzt alles wunderbar.

Danke nochmal