Fehler bei Codec Wahl bei incoming calls?

dErEuLe

Neuer User
Mitglied seit
24 Mai 2004
Beiträge
30
Punkte für Reaktionen
0
Punkte
0
Hallo

Nun getraue ich mich mal wieder einen Beitrag ins Forum zu schreiben. Ich könnte hier und jetzt ausholen und meinen Leidesweg bis ins letzte Detail ausführen, aber das möchte ich jedem ersparen.

Nur so viel:
Ich habe jedes Sipura Gerät durchgetestet und keines lief so, wie hier im Forum beschrieben. Alles habe ich versucht! Portforwarding, DMZ, Stun und das auch noch in allen erdenklichen Kombinationen. Anfangs hat immer alles einwandfrei funktioniert, aber dann so 10-20 Stunden später kamen keine einkommenden Anrufe mehr an. Das heisst geklingelt hat es, aber sobald ich den Call entgegen nahm, hörte die Gegenseite "diese Rufnummer ist ungültig". So nebenbei erwähnt habe ich das ganze mit sipgate und sipcall versucht - mit dem gleichen Ergebnis. IP Calls waren davon nicht betroffen nur Fixnet.

Nun aber seit 2 Tagen funktioniert es irgendwie - it's magic :) - oder doch nicht?!

Normalerweise habe ich, aufgrund beschränkter Bandbreite, immer den 726-32 Codec verwendet, aber wollte nun doch mal einfach mit dem 711u als preffered Codec arbeiten. Siehe da, irgendwie scheint es nun zu gehen.

Kann diese Beobachtung jemand bestätigen? Ist Sipura zu wenig schnell, wenn es um die Codec Auswahl geht und bricht die Verbindung ab?

Noch ein weiterer Punkt:
Ich habe ein Problem mit der Wahl von Mobilnummern über Sipgate. Nur selten bringe ich eine Verbindung hin, was aber Sipgate überhaupt nicht davon abhält trotzdem Gebühren zu verrechnen.
Habt ihr das auch schon beobachtet? Mit meinem anderen Provider funktioniert es immer tadellos.

Cheers
dErEuLe
 
Ok, Sipgate und Codecs: Wenn G.711, also einer der beiden PCM-Codecs verfügbar ist, wird der automatisch genommen, aber das hat mit Deinem Problem anscheinend nicht viel zu tun.

Habe mir gerade mal die INVITE-Nachricht von Sipgate angesehen. Dort bietet Sipgate folgende Codecs an: PCMA, PCMU, GSM, iLBC, G729, G726-32. Das von Dir beschriebene Phänomen wäre denkbar, wenn Du einen der Sipura-Codecs als prefered only eingetragen hast, den Sipgate nicht kann. 726-32 sollte aber laut INVITE gehen.

Ich brauche ein paar Informationen von Dir:
- Hast Du die Möglichkeit, den SPA mal ohne Router zu betreiben?
- Bei welchen Codecs funktioniert es? Hast Du prefered only auf YES eingestellt? (Achtung, bei NO wird bei Sipgate immer der PCM genommen)
- Kannst Du mal bitte den syslog eines nicht funktionierenden ankommenden Gespräches einstellen (ab INVITE bis zum BYE, bitte Rufnummern und Nutzerdaten rausXXen)
 
Vielen Dank für die Antwort.

Ich möchte Deine Fragen ganz sec beantworten:
- Nein, leider geht das nicht
- Nein, dieses Feature hatte ich schon immer auf NO. Bis jetzt funktioniert hat es nur mit dem 711u - auch heute wieder. Habe nun erneut auf 729a umgestellt...
- ... mal schauen, ob demnächst mal ein Fall eintritt, wo es nicht geht. Diesen würde ich dann posten.

Thx.

(übrigens die "Next Registration In" Time habe ich auf 300sek eingestellt)
 
Wenn Du prefered only immer auf NO hattest, wurde eingehende calls immer mit einem der PCM-Codecs verbunden. Ändere mal auf YES und probiere die oben genannten Codecs durch.

Wie gesagt, ein syslog-Mitschnitt könnte schnell Klarheit geben.
 
Einstellung auf Yes gestellt und 729a ausgewählt und schwuppdiwupp hier ein syslog, wo es schief gelaufen ist:


[0:5060]<<212.117.200.xxx:5060
OPTIONS sip:[email protected]:5060 SIP/2.0

[0:5060]->212.117.200.xxx:5060


[0:5060]<<212.117.200.xxx:5060
INVITE sip:[email protected]:5060 SIP/2.0

[0:5060]->212.117.200.xxx:5060


[0:5060]->212.117.200.xxx:5060


[0:5060]<<212.117.200.xxx:5060
ACK sip:[email protected]:5060 SIP/2.0

[0:5060]<<212.117.200.xxx:5060
OPTIONS sip:[email protected]:5060 SIP/2.0

[0:5060]->212.117.200.xxx:5060


[0:5060]->212.117.200.xxx:5060


[0:5060]->212.117.200.xxx:5060

Kannst Du mit dem was anfangen?
(zur Info: ich konnte nun aber den Fehler wirklich nur einmal produzieren)
 
Leider nur bedingt, mir fehlen die gesamten Angaben in den einzelnen Nachrichten, da sollte sehr viel mehr stehen als nur die erste Zeile.

Es gibt aber schon 2 Dinge, die mich wundern:

1. die IP, über welchen Provider hast Du es versucht? Sipgate?
2. OPTIONS - habe ich bei Sipgate noch nie gesehen.

Nutze bitte mal Sipgate, da ich das am besten vergleichen kann. Ist der Account bei Sipgate Deutschland oder Östereich?
 
Ich habe das ganze mit sipcall.ch ausprobiert. Auf Line1 ist sipcall und Line2 sipgate.de.

Vielleicht kann ich den Fehler auch mit Sipgate produzieren...
Welchen Debug Level soll ich einstellen? Zur Zeit ist 1-Line eingeschaltet.
 
System -> Optional Network Configuration -> Debug Level: 3
LineX -> SIP Settings -> full
 
Ich habe das alles einmal so eingestellt, aber ich sehe keine Veränderung an den Logs. OPTIONS habe ich sowohl auf sipcall, wie auch auf sipgate.

Den Fehler kommte ich auf Sipgate nicht reproduzieren. Aber heute obwohl 711u bei sipcall eingestellt ist, hörte ich als ich mich selber angerufen habe nach kurzem Warten "Rummer ungülitg" und das obwohl ich das angerufene Telefon gar nicht angefasst habe. ?

Was mich auch sehr suspekt dünkt ist die Tatsache, dass wenn ich über sipgate telefoniere das Gespräch nur selten zu stande kommt. Ich höre gar nichts, bis die Gegenseite das Telefon annimmt, dann ertönt das Besetztzeichen und das Gespräch wird berechnet. ?
 
Hallo Robinson.

Ich habe den SPA so wie Du es vorgeschlagen hast konfiguriert. Anders sehen für mich die Daten nicht aus, aber vielleicht siehst Du darin etwas.

06-11-2005 13:37:39 192.168.xxx.xxx <010>
06-11-2005 13:37:39 192.168.xxx.xxx [1:5061]<<217.10.79.9:5060
06-11-2005 13:37:07 192.168.xxx.xxx <010>
06-11-2005 13:37:07 192.168.xxx.xxx [1:5061]->217.10.79.9:5060
06-11-2005 13:37:07 192.168.xxx.xxx <010>
06-11-2005 13:37:07 192.168.xxx.xxx [1:5061]<<217.10.79.9:5060
06-11-2005 13:36:35 192.168.xxx.xxx <010>
06-11-2005 13:36:35 192.168.xxx.xxx [1:5061]->217.10.79.9:5060
06-11-2005 13:36:35 192.168.xxx.xxx <010>
06-11-2005 13:36:35 192.168.xxx.xxx [1:5061]<<217.10.79.9:5060
06-11-2005 13:36:19 192.168.xxx.xxx <010>
06-11-2005 13:36:19 192.168.xxx.xxx [1:5061]->217.10.79.9:5060
06-11-2005 13:36:19 192.168.xxx.xxx <010>
06-11-2005 13:36:19 192.168.xxx.xxx [1:5061]<<217.10.79.9:5060
06-11-2005 13:36:02 192.168.xxx.xxx <010>
06-11-2005 13:36:02 192.168.xxx.xxx [1:5061]->217.10.79.9:5060
06-11-2005 13:36:02 192.168.xxx.xxx <010>
06-11-2005 13:36:02 192.168.xxx.xxx [1:5061]<<217.10.79.9:5060
06-11-2005 13:35:46 192.168.xxx.xxx <010>
06-11-2005 13:35:46 192.168.xxx.xxx [1:5061]->217.10.79.9:5060
06-11-2005 13:35:46 192.168.xxx.xxx <010>
06-11-2005 13:35:46 192.168.xxx.xxx [1:5061]<<217.10.79.9:5060

Ich habe einmal zwei Screenshots vom Info Fenster des SPAs gemacht. Einmal einen incoming call auf sipcall und den anderen auf sipgate. Irgendwie wundert es mich nicht, dass ich bei sipgate nur eine Einwegaudiostrecke habe.

Was sagst Du dazu?
 

Anhänge

  • incoming_sipcall.jpg
    incoming_sipcall.jpg
    49.8 KB · Aufrufe: 10
  • incoming_sipgate.jpg
    incoming_sipgate.jpg
    46.3 KB · Aufrufe: 13
Also eigentlich sollte der Mittschnitt die Form haben, wie der Code-Abschnitt in diesem Thread: http://www.ip-phone-forum.de/forum/viewtopic.php?t=18647 . Du hast nur die Zeiten (die in dem Thread fehlen), die Ports und IPs gepostet, damit kann ich leider nichts anfangen.

Der 2. Screenshot sieht gut aus, sehe keinen Fehler. Das Gespräch im 1. ist noch nicht aufgebaut.
 
Es kann sein, dass das Gespräch noch nicht aufgebaut war, aber es kam nicht mehr zu stande. Das ist alles, was passiert ist.

Ich habe es endlich geschafft richtige Logs zu ziehen. Der Fehler lag an der Einstellung. Ich hatte nur den Syslog Server eingetragen und nicht den Debug Server - Anfänger! :)

Die beiden Logfiles sind angehängt... ist daraus etwas abzuleiten?
(misslungenes Gespräch: Anrufer erhielt Besetzzeichen, als ich den Anruf entgegen genommen hatte)
 

Anhänge

  • misslungen.txt
    12.6 KB · Aufrufe: 6
  • gelungen.txt
    12.4 KB · Aufrufe: 7
Grrr, Du machst es einem aber auch nicht leicht, vollkommen ungeordnet in einem durchlaufenden String den SIP-Mitschnitt :iih: :grab:

Aber ich habe ihn doch durchforstet und den Fehler wahrscheinlich gefunden - es liegt wohl nicht an Dir.

Normalerweise läuft der Aufbau so: INVITE (eingehend), Trying (ausgehend), Ringing (out), [Hörer abnehmen], 200 OK (out), ACK (in)
Das passiert auch im gelungenen Gespräch, zusätzlich sind da wieder ein paar OPTIONS und die dazugehörenden 200 OK, die aber anscheinend keine Rolle spielen.

Im mißlungenen Fall läuft es so: INVITE (in), Trying (out), Ringing (out), ACK (in), [Hörer abnehmen], 200 OK [out]
D.h. das Acknowledge, also die Bestätigung vom Provider und damit das Aufschalten des Gespräches, kommt noch vor dem Abnehmen des Hörers und dem erst dann ausgelösten 200 OK, was natürlich zum Fehler führt.

Die Geschichte sollte SipCall erfahren, ich denke nicht, dass es was mit den Codecs zu tun hat.
 
Im mißlungenen Fall läuft es so: INVITE (in), Trying (out), Ringing (out), ACK (in), [Hörer abnehmen], 200 OK [out]
D.h. das Acknowledge, also die Bestätigung vom Provider und damit das Aufschalten des Gespräches, kommt noch vor dem Abnehmen des Hörers und dem erst dann ausgelösten 200 OK, was natürlich zum Fehler führt.

Also genau dieses Verhalten habe ich auch mit dem holländischen Provider Talkin2ya wenn auf dem SPA-1001 eine neuere Firmware als 2.0.12(SEa) installiert ist. Mit der 2.0.12(SEa) läuft es jedoch ohne Probleme...
 
Habt vielen Dank für die Unterstützung!!!! Ich werde sipcall einmal darüber in Kenntnis setzen. Natürlich werde ich anschliessend wieder einen Beitrag posten.

Tut mir leid, dass die Logs so hässlich waren, aber ich dachte ihr braucht alle Details.

Cheers
dErEuLE
 
dErEuLe schrieb:
Tut mir leid, dass die Logs so hässlich waren, aber ich dachte ihr braucht alle Details.
Kein Problem, weiß ja, dass es immer ein Krampf ist, die Daten lesbar aufzubereiten. Ich hab sowieso immer was zu meckern ;-)
 
Ich habe einmal sipcall über den Sachverhalt informiert. Bin gespannt, was da zurückkommt.

Nun aber noch zu etwas ganz anderem. Mein ISP vergibt mir täglich eine neue IP Adresse. Nach jedem Wechsel kann ich nicht mehr angerufen werden. Das heisst, der Effekt ist eigentlich immer derselbe. Telefon klingelt, ich nehme ab und der Anrufer hört "Rufnummer ungültig". Beim zweiten Versuch scheint es zu funktionieren.

(übrigens habe ich die neue SPA Firmware (3.1.3?) seit gestern im Betrieb)
 
In der LineX bei NAT Settings "NAT Mapping Enable" auf Yes und STUN aktivieren (SIP-Reiter unten alles auf Yes und z.B. "stun.sipgate.net:10000" als STUN-Server eintragen).
 
Du wirst es mir nicht glauben, aber mein SPA war schon immer mit STUN und NAT Mapping Enable konfiguriert - auf beiden Linien. Alle NAT Support Parameter sind auf YES. Die Ports am Router sind auch immer noch geforwardet.
 
Glaub mir, ich glaube mit der Weile alles :)

Wie oft registrierst Du Dich noch gleich beim Provider?
Haste das gleiche Problem auch mit dem andere Router (unwahrscheinliche Lösung)?
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.