DDD schrieb:
Warum die antwort da so spät kommt, kann an Telefonica alleine ja nicht liegen, sonst hätten es auch Sipgate und co. Evtl. ist eine verbindung von Telefonica zum Carpo Server da, und da stockt es ab und zu mal ein wenig?!
Laut eines mir recht kompetent erscheinenden Carpo Support Mitarbeiter liegt das Problem genau an der Schnittstelle zwischen dem Mediagateway von Telefonica und dem SIP-Server von Carpo. Bei einem ankommenden Anruf über das Festnetz kontaktiert das Mediagateway von Telefonica zuerst den Carpo SIP-Server (um festzustellen, ob der Account gültig ist), dann das Endgerät des Nutzers (somit klingelt es dort). Nach der Gesprächsannahme durch den Angerufenen geht das Ganze wieder retour, d.h. vom Endgerät (z.B. Fritzbox) zum Mediagateway und dann zu Carpo (um zwecks Billing den Gesprächsbeginn festzuhalten) und erst wenn diese Antwort von Carpo an das Mediagateway bestätigt wurde, signalisiert das Mediageatway per SS7 dem Festnetz "Rufanahme" (d.h. es Ende des Klingelns) und das Mediagateway leitet die RTP Pakete (d.h. die Audio-Daten) an das Endgerät weiter.
Lt. Carpo Support liegt der Fehler an der Kommunikation zwischen Mediagateway und dem SIP-Server von Carpo. SIP ist jedoch ein recht komplexes Protokoll, bei dem jedes beteiligte Endgerät Informationen hinzufügen oder herausnehmen kann.
Stand letzter Woche war, daß die von der Fritzbox erzeugte Rückantwort ("200 OK") - warum auch immer - zu lang ist und vom Mediagaway in 2 UDP-Pakete zerlegt wird und der SIP-Server aufgrund einer nicht näher spezifierten Firewall nur das erste erhält und somit die SIP-Nachricht über die erfolgreiche Rufanahme unvollständig ist. Da die Antwort des Carpo-Servers ausbleibt, signalisiert das Mediagateway entweder keine Rufanahme (der Anrufer hört weiterhin ein Klingelton) oder es kommt zu einem Timeout und somit einem Besetzt ("slow busy" beim Anrufer, SIP-Fehler "487 Busy here" beim Angerufenen).
Bei anderen Providern (z.B. Sipgate, Outbox-Reseller), die ebenfalls auf Telefonica setzen, tritt dieserFehler nicht auf, weil diese die Gespräche in ihrer Infrastruktur terminieren und somit keine SIP-Nachrichten der Fritzbox direkt an das Mediagateway von Telefonica gelangen. Im Normalfall (d.h. wenn alles funktioniert) ist dieses Vorgehen ungünstig: Die Voicedaten müssen erst zum VoIP Anbieter hin und wieder zurück. Dies kostet den Anbieter Geld und birgt andere Probleme (Skalierbarkeit, höherer Wahrscheinlichkeit eines Komplett-Ausfalls). Selbst wenn Carpo wollte, könnte man dies nicht kurzfristig ändern: Ich glaube kaum, daß Carpo in Prag die notwendige Infrastruktur vorhalten könnte um die Gespräche dort zu terminieren und weiterleiten zu können.
Ich verstehe dennoch nicht, warum - wenn das Problem bereits so weit eingekreist wurde- man es nicht schafft, diese Firewall oder was auch immer es ist zumindest temporär soweit zu öffnen, daß die Signalisierung wieder funktioniert. Erschwerend kommt hinzu, daß es im SIP-Standard einige unbestimmte Variablen gibt (z.B. Max. Länge des Contact-Headers) und somit Schuldzuweisungen schwierig sind. Aber genau dann müssen eben die Systeme flexibel genug sein...
Umgehen kann man das Problem wie schon hier beschrieben durch Nutzung eines der öffentlichen Proxydienste oder die Einrichtung eines eigenen Asterisk-Servers (z.b. auf der Fritzbox...).
Ich nutze einen gehosteten Asterisk und habe dort weiter Eigenheiten des Mediagateways von Telefonica beobachtet: Terminiert man die Gespräche auf dem Asterisk ("canreinvite=no"), so funktioniert alles wie gewünscht (nur dass man dann eben die Voice-Daten ankommend und abgehend in Form von Traffic "bezahlt"). Aktiviere ich dagegen "canreinvite=yes", versucht der Asterisk per SIP-REINVITE den Audiostream umzuleiten. Bei vielen Anbietern funktioniert dies in Verbindung mit einer Fritzbox als Endgerät einwandfrei. Bei Telefonica-Resellern leitet zwar das Mediagateway die Audiodaten danach direkt an die Fritzbox weiter - zusätzlich kommt eine Kopie der Daten beim Asterisk an. Sehr wahrscheinlich ist dieses weitere Fehlverhalten des Telefonica-Gateways Ursache dafür, warum Carpo Rufnummern nur bei wenigen öffentlichen Proxies funktionieren).
Auf diese Weise ist man aber jedenfalls erreichbar - zugegeben ist dies nur eine Lösung für eine kleine Minderheit der Kunden von Carpo, die Zugrif auf einen Asterisk-Server haben.
Jens