Posts by bytegetter

Ausprobieren. Eigentlich ja, aber: Im Standard steht: Hätte könnte müsste sollte. Und die Starface selbst macht ja ihren Voodoo noch mit dazu.

Könntest ja mal probieren, was passiert, wenn du die Reihenfolge änderst, also g.722 zum Schluss stellst. Die Aushandlung sollte damit "eigentlich" bewirken, dass der erste gemeinsame Codec gewählt wird.

Ich finde es übrigens erstaunlich, dass sich Starface aus dem Thread raushält.

pasted-from-clipboard.png

In der Endgerätekonfig.

Aber irgendwie kamen die, glaube ich, wieder. Da war mal vor ein paar Jahren was.

Bei g.722 funktioniert DTMF nicht.

Calls, die über Gateways kommen (Versatel hat z.B. noch große Kunden so angebunden) haben nur alaw/ulaw. Da A nur alaw/ulaw kann und B nur g.722 spricht wird der Verbindungsaufbau abbrechen. Versatel transcoded zum Beispiel nicht. Wenn dein Provider transcoded (braucht viel Resourcen oder eine dedizierte Transcodingkarte im SBC) dann kann aber nicht muss er transcoden. Ausprobieren.

Mit sip show channels fällt mir am Asterisk ein hoher Anteil von g.722 calls auf, obwohl die zum SIP-Trunk hin deaktiviert sind. Ist das bei euch auch so?

Das ist aber kein Problem mit den Übergangswiederständen der Ladekontakten, wo man die Federn nachbiegen musste (Mitte der 90er Jahre, Mega oder Gigaset, weiss ich nicht)?

slu

Lassen wir mal die Starface und das merkwürdige Codec-Gemauschel so wie es ist und stellen uns einfach vor, dass die Starface B2BUA spielt und im Zusammenspiel SIP-Trunk und Endgerät nicht mehr transcoded als nötig.

Nun kennen wir ja das Verhalten der Starface mit den Wartemusiken, bei dem nicht das Original WAV in der Lautstärke verändert wird, sondern das WAV immer wieder manipuliert und bei jedem Durchgang schlechter wird. (*2)

Du kannst dich sicher noch an das IVR-Modulproblem erinnert, wo bei "falscher" Rufnummer der Call zwar zustande kam, aber RTP nicht funktionierte.

Stellen wir uns einfach mal vor, dass bei einem Modul der Call mitsamt RTP "durch" das Modul geht. Jedes Modul bekommt also den ganzen RTP-Stream als fertiges Endprodukt der vorherigen verarbeitenden Instanzen. Wie entwickelt sich denn die Gesprächsqualität, wenn du den Call z.B. 10 mal durch die Kette Modul->Gruppe->Modul leitest und im Modul entweder oder answer() und playback() machst? Evtl. erzeugt jedes Answer() ein Volume=0.9?

(2):

Wenn ein Playback() auf in der Lautstärke verändertes .wav durchgeführt wird hat der Programmierer evtl. vergessen, das Volume=0.x zu löschen?

Frage: Welcher Codec verwendet ein Modul bzw. welche Codecs kann ein Modul verarbeitet und wo muss die Starface transcoden?

Beispiel: g.722 kommt vom SIP-Trunk, Call geht in Gruppe, von da in ein Modul (welches eine Ansage spielt), dann zum Endgerät das nur alaw spricht. Wieviele Instanzen transcoden den gleichen Call und warum?

Bei immer sieht der Aufbau im Callcenter immer so aus:

Eingangsgruppe als Durchlauferhitzer für die DDI -> IVR-Modul -> Gruppe für Statistik -> Gruppe für iqueue -> Endgerät

Kann Starface mal erläutern welche Schleife hier RTP macht und wie oft transcoded werden "muss"? Jeweils mit allen Varianten g.722/alaw/ulaw auf Seiten SIP-Trunk und Endgerät?

Ich meine hier die Codecreienfolge im SDP und in der logischen Konfiguration der Endgeräte. Ich vermute dass evtl. irgendwo eine Reihenfolge nicht passt (erst ulaw und dann alaw im Trunk, im Endgerät dann umgekeht), so dass die Starface überzeigt ist transcoden zu müssen. Auch wäre es möglich, dass die Starface den SDP irgendwo falsch rum auswertet oder die Einträge sortiert und deshalb transcoded.

Weil ich nun neugierig wurde habe ich mir nun einen Inbound-Call auf der Starface angesehen und war etwas erstaunt.

Beispiel:

SIP-Trunk, inbound-Call:

o=anonymous 166558474804 166558474804 IN IP4 79.140.113.2

s=SIP Call

c=IN IP4 79.140.113.67

│t=0 0

m=audio 35836 RTP/AVP 9 8 0 100

b=AS:82

a=rtpmap:9 G722/8000/1

a=rtpmap:8 PCMA/8000/1

a=rtpmap:0 PCMU/8000/1

a=rtpmap:100 telephone-event/8000

a=fmtp:100 0-15

a=ptime:20

a=sendrecv

Starface schickt einen Invite zum Yealink:

o=root 1251296482 1251296482 IN IP4 217.70.132.17

s=STARFACE PBX

c=IN IP4 217.70.132.17

t=0 0

m=audio 18850 RTP/AVP 8 9 0 101

a=rtpmap:8 PCMA/8000

a=rtpmap:9 G722/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

a=maxptime:150

a=sendrecv

Yealink antwortet:

o=- 20028 20028 IN IP4 192.168.200.15

s=SDP data

c=IN IP4 192.168.200.15

t=0 0

m=audio 12486 RTP/AVP 8 101

a=rtpmap:8 PCMA/8000

a=ptime:20

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=sendrecv

Starface antwortet dem Provider in der 200OK:

o=root 1974025316 1974025316 IN IP4 217.70.132.17

s=STARFACE PBX

c=IN IP4 217.70.132.17

t=0 0

m=audio 17754 RTP/AVP 8 0

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=ptime:20

a=maxptime:150

a=sendrecv

Den Call zwischen Starface und iPhone (Starface-App) sehe ich hier nicht.

Nun entstehen daraus folgende Fragen:

Wieso invitet die Starface das physische Endgerät mit g722, wenn von aussen alaw/ulaw reinkommt? Wieso beantwortet die Starface dem Invite des Providers mit alaw/ulaw wenn das Endgerät nur alaw will?

Die kann doch früher oder später nur transcoden.

M.e. nach hätte die Starface im 200OK an den Provider nur alaw signalisieren dürfen, oder? Dieses Problem (Codec in der 200OK bei transfer eines laufenden Calls an eine Nebenstelle mit anderer Codec-Funktionalität (z.B. eine Ansage/MOH mit alaw oder Transfer auf a/b-Wandler) und fehledem RTP) war auch Thema im IOP-NW (Interoperabilitätsnachweis im Wirknetz) mit der Telekom.

Nun unterstelle ich dem Asterisk-Unterbau die Codecs richtig zu verarbeiten. Was macht aber nun die Starface, wenn da weitere Geräte über die Apple-Schnittstelle drangebastelt wurden? Hat mal jemand Lust, das zu zerlegen?

slu: Haben deine Nutzer neben den Gigasets noch weitere Geräte an der gleichen Nebenstelle (MAC-Client, iPhone oder Android-App) aktiv? Wird vor deinen Gesprächen noch eine Ansage, MOH oder iQueue geschaltet?

Nachtrag:

Bei einem Transfer könnte die Starface einen re-invite zum Provider mit der Bitte eines Codecwechsels schicken (diese kann aber wieder abgelehnt werden, ist erlaubt), der dann über den eigenen Provider zum ursprünglichen A-Endgerät durchdekliniert wird. Hier wäre zu vermuten, dass die Starface aus vereinfachungsgründen einfach den Call intern trancodet.

Wenn man die Vereinfachung aus dem letzten Absatz weiter spinnt halte ich es auch für möglich, dass die Starface gar keinen externen reinvite macht.

Evtl:

Falsche Reihenfolge ulaw/alaw in einem Templete und deshalb unsinniges Transcoding?

Ich hatte einfach G.722 abgeschaltet, dann war Ruhe. Egal ob mit dem Softclient am MAC oder den Yealink-Telefonen.

Das Problem trat bei uns auch mit den Yealinks und dem Softclient ma MAC auf.

Per root drauf und in die Logs schauen. Ob da smartctl installiert ist kann ich dir nicht sagen.

Alternativ mit Holzhammer: Von USB neu installieren und gucken ob es dann besser läuft (voodoo).

ssd geprüft?

Vielleicht sollte man mal die Default-Einstellung überarbeiten. Ich muss bei jedem neuen User daran denken ihm das Recht zu nehmen.

Die Namensauflösung scheint ein grundlegendes Problem zu sein und funktioniert auf der MAC-Version schon seit Jahren nicht richtig. Es wurde zwar immer wieder "verbessert", das grundlegende Problem aber nie behoben.

Man müsste den ganzen Unterbau zerlegen und prüfen wo und warum das ganze irgendwann anfängt zu transcoden. Das ist so ähnlich dem Fehler, dass interne Calls nur einseitig waren, wenn man intern von Gruppe/Modul zu Gruppe/Modul mit einer nicht qualifizierten Rufnummern gearbeitet hat (Zielnummer im IVR z.B. 03012345689 anstelle von 00493012345689 gab einseitig Verständigung).

Quote from mm@sigma-it.de

Blöde Frage: Wie stelle ich auf 711 um ? Beim Telefon des Users unter Erweitert den 722 rausnehmen ? Oder geht das auch Zentral ?

Hier waren nur externe Gespräche betroffen. Es reicht g.722 in der Leitungskonfiguration zu sperren.

Das Problem gab es sowohl bei den Yealinks als auch über die MAC-App.

Die Calls gehen bei mir z.T. durch IVRs und mehrere Gruppen als Durchlauferhitzer. Vom Prinzip her nichts, was RTP kaputt machen sollte. Scheinbar wird aber irgendwo im Call mehr im RTP eingegriffen, als dem RTP gut tut (B2B-Useragent als Verhalten, obwohl gar nicht nötig).

Ich hatte das eine zeitlang seit den 6.er Versionen finales HD/G.722 abschalten brachte Hilfe.

Als bei uns Monatelang die Buchhaltung zu blöde äh vergessen hatte die Rechnung zu bezahlen kam dort tatsächlich ein 404.