Geisterklingeln mit Nokia E65

[pumana]

habe folgendes Problem.
Benutze Nokia E65 mit voipcheap. Einrichtung und Anmeldung klappen wunderbar. Telefonieren auch. Wenn ich einen Anschluß anrufe und dann auflege klingelt es nach etwa 30 Sekunden bei der anderen Seite wieder! Woran könnte das liegen, gibt es evtl eine Lösung?

 

[pumana]

Ich kopiere mal die Antwort von Nokia Support hier.

Sehr geehrter Herr ,

herzlichen Dank, dass Sie mit dem NOKIA Contact-Center Kontakt aufgenommen haben.

Bitte setzen Sie sich in dieser Angelegenheit mit Ihrem VoiP Anbieter in Verbindung.

Wenn Sie noch weitere Fragen oder Anregungen haben sollten, können Sie sich jederzeit wieder an uns wenden.

Mit freundlichen Grüßen

NOKIA Service Professional
NOKIA Contact–Center

:-Ö

 

[freak0815]

Hallo,
hast du schon eine Lösung für dieses Problem? Ich habe das E65 auch seit heute und dieselbe Problematik.

 

[ssteiner]

Kannst du mal den SIP Traffic aufzeichnen?
Mir haben sie genau dasselbe gesagt als ich mit meinem SPA9000 Registrationsproblem gekommen bin, ich habe das aber nicht auf mir sitzen lassen, musste aber schlussendlich doch selbst anhand der Traces und des SIP RFCs herausfinden was genau schiefläuft. Das Problem mit dem Geisterklingeln habe ich schon mit dem Linksys WIP300 erlebt, ich denke da werden wir schon herausfinden was genau schiefläuft und wer an der Misere schuldig ist.

 

[pumana]

Nein, bis jetzt habe ich keine Lösung des Problems. Wie kann ich auf dem Nokia E65 ein SIP Traffic Protokol machen? Gibt es evtl Zusatztools?

 

[detejo]

auf dem E65 selbst geht es IMHO nicht. aber zwischen E65 und Provider befindet sich meist ein Router.

 

[freak0815]

So, ich habe jetzt zuhause getraced. Mit der Fritzbox geht das ja ganz schön.
Ich habe direkt auf PPPoE getraced und gesehen, dass in meinem Fall ein SIP/SD Invite Request an den SIP-Server rausgeht. Das sieht wohl eher nicht nach Provider-Problem aus, sondern nach dem E65

 

[ssteiner]

SIP/SD Invite Request? Was ist denn das? Könntest du mal den gesamten Trace posten (Rufnummern kannst du ja ersetzen wenn du willst, den auth header auch), inkl. Angabe was wann passiert.

Also z.B.

Hier wähle ich die Nummer xyz vom E65 aus:

INVITE xyz

180 Trying

110 Ringing

Hier nimmt xyz den Hörer ab:
200 OK

Hier lege ich auf (es kann ne Rolle spielen wer zuerst auflegt)
BYE

200 OK

...

und hier klingelt es bei der Gegenstelle nochmals

...

hier nimmt die Gegenstelle ab

 

[pumana]

Hier nimmt xyz den Hörer ab:
200 OK

Das Problem taucht eben NICHT auf, wenn die Gegenstelle abnimmt. Nur wenn man vorher auflegt, klingelt es nach etwa 20 Sekunden bei der Gegenstelle wieder.

 

[ssteiner]

Aber auch in dem Fall sind Traces nützlich - das tönt ziemlich ähnlich wie das, was ich mit dem WIP300 erlebt habe (ich breche ab bevor die Gegenstelle abnimmt, und es klingelt munter weiter - der Grund war ein nicht korrektes CANCEL vom WIP300).
Kannst du die Aufzeichnung starten bevor du die Nummer anrufst, und beenden nachdem es am andern Ende wieder anfängt zu klingeln nachdem du auf dem E65 den Anrufversuch abgebrochen hast.

 

[pumana]

So, habe gerade ein Test mit meinem E65 und Carpo gemacht. Verbindung wird getrennt und es klingelt nicht mehr wieder beim Angerufenen. Also es scheint doch ein Betamax-Problem zu sein. VoIPCheap und Webcalldirect scheinen davon betroffen zu sein. Vielleicht können andere Nokia E65 Nutzer über andere Betamax-Clone berichten, ob da auch dieses Geisterklingeln auftaucht.

 

[freak0815]

So, hier wäre mal der Trace in aller Ausführlichkeit.
Den habe ich gestartet, direkt nachdem ich meinen Testanruf beendet habe. Der Trace zeigt nur das Geisterklingeln.

Das Problem taucht eben NICHT auf, wenn die Gegenstelle abnimmt. Nur wenn man vorher auflegt, klingelt es nach etwa 20 Sekunden bei der Gegenstelle wieder.

Das sieht bei mir anders aus. Das Problem tritt immer auf und es dauert ca. 4-5 Minuten bis zum Geisterklingeln.

 

[ssteiner]

Es wäre trotzdem interessant zu sehen wie der ganze Anruf aussieht.. das ist jetzt nur ne Vermutung, aber wenn das E65 für sein Cancel keine vernünftige Bestätigung kriegt.
By the way.. diese Testanrufe scheinen mir an ne SIP URI und nicht ne reguläre Telefonnummer zu gehen.. wie sieht das Szenario da genau aus? (Standort Anrufer und Angerufener, entsprechende Provider und ob die Anrufe via SPI URI oder Telefonnummer geroutet werden). Ich würde zuerst mal ne reguläre Festnetznummer oder Mobilnummer anrufen, und danach Schritt für Schritt das Szenario "verkomplizieren".

@freak0815: sehe ich das richtig.. das E65 macht nen zweiten Anruf, der wird beantwortet, und dann abgeschossen (BYE kommt vom IPTSP zurück), und das E65 antwortet darauf mit 481 (obwohl es den Anruf ja ausgelöst hat.. das überflüssige INVITE kommt ja vom E65)

 

[freak0815]

@freak0815: sehe ich das richtig.. das E65 macht nen zweiten Anruf, der wird beantwortet, und dann abgeschossen (BYE kommt vom IPTSP zurück), und das E65 antwortet darauf mit 481 (obwohl es den Anruf ja ausgelöst hat.. das überflüssige INVITE kommt ja vom E65)

Exakt, das Abschießen kommt, weil der Angerufene aber auch rein garnichts hört: Es klingelt, man geht ran und die Leitung ist still, dann wird sofort aufgelegt.

 

[spongebob]

Da hast Du Dir aber Mühe gegeben mit dem "Aus-Xen"... Und dann im Hexdump die Binärdaten vergessen, tss, tss...

Aber egal. Dem Thread zufolge hätte ich auch auf ein fehlerhaftes CANCEL getippt, aber Dein Trace zeigt nur, dass der Server sich über das falsche BYE beschwert. (EDIT: Korrektur nächster Absatz) Angeblich Status: 481 Call/Transaction Does Not Exist. Ich kann das nachvollziehen, verabschiedet sich der Client doch mit einem CSeq 0 im BYE...

EDIT: Hab mir den Trace noch mal genau angesehen. Das BYE kommt vom Netz und somit halte ich die Antwort des E65 (481...) für OK, denn ein freifliegendes BYE ohne CSeq, hmmm...

So, wie es aussieht, ist der Call damit nicht wirklich terminiert.

Besser wäre es wirklich, den Trace in .cap Form an die Interessenten zu vermailen. Ein gewisses Mass an Vertrauen kann man schon vorschiessen. Zumal - ausser Deinen Rufnummern kann man nicht wirklich was Verwertbares aus dem Trace entnehmen.

Schön ist auch die von Wireshark bei der Call-Analyse erzeugte Grafik. Ggf. kannst Du da ja noch mit einem Grafik-Tool die Rufnummern "verwischen".

Grüsse

 

[freak0815]

Also für mich sieht das sauber aus.
Was meinst du mit nicht richtig terminiert? Den Ursprungs-Call? Sollte ich vielleicht einen Trace von beiden Calls machen?

 

[spongebob]

Na ja, die Grafik zeigt es ja: Der Call ist nie korrekt aufgebaut worden. So ist z.B. keines der Signale TRYING und PROGRESS und auch nicht das 200 OK vom Server "geackt" worden. Das müsste man sich noch mal genauer ansehen, aber das geht komfortabel nur auf Binärebene.

Mach mal einen Trace von der Gesamt-Kiste, speicher den im (Standard) libpcap Format und schicke es per Mail an die Interessenten. Vielleicht auch noch mal ein paar Kommentare auf der Tonspur ("Dann habe ich das gemacht...")

Grüsse

 

[ssteiner]

@spongebobb: siehst du das nicht gerade in die falsche Richtung? Wenn ich mich nicht schwer täusche enthält der Trace folgendes

E65 -> IPTSP: INVITE
IPTSP -> E65: 100 Trying
IPTSP -> E65: 183 Session Progress
IPTSP -> E65: 180 Ringing
IPTSP -> E65: 200 OK
(jetzt wäre der Zeitpunkt wo das E65 ein ACK an den Server zurückschicken sollte)
IPTSP -> E65: BYE
E65 -> IPTSP: 481 Call/Transaction does not exist

Hat sich jemand mal die Zeitstempel angesehen?
200 OK : Arrival Time: May 21, 2007 20:24:11.216001000
BYE: Arrival Time: May 21, 2007 20:24:16.576001000
481: Arrival Time: May 21, 2007 20:24:16.676001000

Das E65 reagiert prompt auf das 481, aber es schert sich einen Dreck um das 200, das wirft doch Fragen auf (ohne jetzt wieder dir RFC hervorzukramen würde ich vermuten dass ein 200 für eine nicht bekannte Transaktion auch zu einem 481 führen sollte).

 

[spongebob]

Ja, richtig. So, wie Du das beschreibst, ist das schon. Das E65 ruft an, nach 14 s kommt das OK, nach weiteren 5 s das BYE vom Netz. Das E65 antwortet lediglich 5 s nicht auf das OK. Na und? Normalerweise würde das Netz den STATUS 200 OK 3 mal wiederholen (mit 3 s Abstand) und dann sich verabschieden. Der STATUS 200 kommt auch noch mit einer korrekten CSeq Referenz auf das INVITE (934). Lt. Grafik läuft in der Zwischenzeit nicht mal das übliche RTP Geklingel...

Wie auch immer: Diese verknappte txt Form ist zu mühselig zum Analysieren. Ich denke, man kann das Problem finden, aber dann nur im Kontext aller vorherigen Signale und in Binärform.

Grüsse

 

[freak0815]

So, jetzt habe ich einen kompletten Trace - Ursprungscall und das Geisterklingeln.
Beim Reproduzieren fiel mir auf, dass das Phänomen vermutlich nur dann auftritt, wenn der Ursprungsanruf nicht entgegengenommen wird (Anrufer legt auf, bevor Angerufene abhebt). Gibt es in SIP vielleicht auch so ein Feature wie "Automatische Wahlwiederholung falls nicht erreichbar?"
Wer den Trace möchte -> einfach PN schicken.