[easybell] Probleme mit Outbound: Kein Freiton; jedoch Klingeln beim Empfänger; Kein Gespräch

[Patrick Baeumel]

Hallo zusammen,

wider Erwarten habe ich die Konfiguration mit etwas basteln für easybell hinbekommen.
(Teils auch schon ergänzend im Wiki eingebaut: https://github.com/amooma/GS5/wiki/easybell)

Nun habe ich aber eine komische Störung/Phänomen, welches ab und an auftritt (Getestet mit meinem Handy als angerufene Partei!)
Nach wählen der Rufnummer habe ich als rufende Partei keinen Freiton in der Leitung.
Das Gerät des Empfängers klingelt aber ganz normal.
Nimmt der Empfänger das Gespräch an, so bleibt die Leitung tot - die Gesprächspartner können sich nicht hören.

Ich habe bei verschiedenen Testanrufen jeweils Sofia Status mitlaufen lassen; kann aber als Anfänger nicht wirklich etwas damit anfangen.

Telefonat OK: Siehe Dateianhänge gemeinschaft_OK.txt, gemeinschaft_OK2.txt, gemeinschaft_OK3.txt

Telefonat mit Fehler wie beschrieben: Siehe Anhänge gemeinschaft_NOK.txt, gemeinschaft_NOK2.txt

 

Auf den ersten Blick fällt mir auf, dass auf Seiten easybell bei den NOK-Telefonaten jeweils ein „Sonus_UAC“ als Gegengerät zum Zuge kam; bei den OK-Telefonaten ein „Cisco“; jeweils auch mit einer anderen IP-Adresse (Sonus = 193.xxx.xxx.xxx; Cisco: 212.xxx.xxx.xxx). Ich habe deshalb versucht statt der Domain „sip.easybell.de“ über die direkte Angabe der IP-Adresse das „Cisco“-Gerät zu erzwingen; aber leider klappt dies nicht. Der Versuch NOK2 zeugt hiervon; es wird wieder das Sonus Gerät angesprochen auf IP 193.xxx.xxx.xxx.

 

Die Sonus-Geräte scheinen netzweit auch als problematisch bekannt; siehe z.B.:

-        http://wiki.freeswitch.org/wiki/RTP_Issues#Carrier_Info

-        http://lists.digium.com/pipermail/asterisk-dev/2009-January/035960.html

 

Hat jemand bei sich easybell laufen und hat das gleiche Problem?

Kann es andere Ursachen geben für das Problem?

 

Ich freue mich über jegliche Tipps und Hinweise.

 

Grüße,

Patrick Bäumel

[Matthias Harder]

Hallo Patrick,

auch wenn Du Unterschiede zwischen den Easybell-Gateways entdeckt hast - ich vermute eher ein Firewallproblem bei Dir.

Wenn deine Telefonanlage hinter einem Router oder einer Firewall steht solltest Du das hier mal lesen:

https://groups.google.com/forum/#!searchin/gs5-users/harder/gs5-users/ZtkIKaZaIow/M_RE9UvO--UJ

Grüße

Matthias

[Patrick Bäumel]

Hallo Matthias,

vielen Dank für den Hinweis.

In meinem Fall hängt die Geminschaft hinter einer FritzBox 7390.
Die FritzBox erlaubt für den Nutzer (ohne tiefe Eingriffe) meines Wissens keine Änderung an den Port-Forwarding-Einstellungen im SIP-Bereich.

Da die FritzBox selber ja SIP macht und kann; frage ich mich nun, ob hier wirklich was gesperrt sein kann.

Weiterhin auch noch die Frage:
Wenn es ein Firwall / Port-Forwarding-Problem sein sollte; müsste dann nicht bei ALLEN Anrufen kein Gespräch zustande kommen?
Von den 5 Testanrufen klappte Verbindung, Rufzeichen und Gespräch aber bei 3 Anrufen.

Ich werde aber heute Abend mal an der FritzBox drehen.

Grüße,
Patrick

[Patrick Bäumel]

Weitere Ergänzung:
Auch wenn ich die Gemeinschaft in der FritzBox als Exposed Host angebe bleibt das Problem.
Zudem habe ich noch in anderen Foren nachgelesen für den VOIP-Bereich hat die FritzBox höchstvermutlich alle UDP-Ports offen.

Weiterhin auffällig an meinem Problem ist auch, dass ich meine Handynummer ja ab und zu korrekt erreichen kann.
Eine Festznetznummer aus München meiner Tante jedoch nie (Kein Rufzeichen; jedoch Klingeln beim Empfänger; aber kein Gespräch)

Eingehende Telefonate von beiden Stellen aus sind aber problemlos!

Grüße,
Patrick

[Matthias Harder]

FritzBox - Ohje, das hatte ich überlesen....

Mal sehen was ich da mit meinem Halbwissen noch dazu beitragen kann:

die Fritzbox hat selbst SIP-Funktionalitäten - folglich sind die entsprechenden Ports nach draußen ohnehin belegt. Hatten schon einige hier - bitte Suche bemühen.... 

Vermute aber dass genau da dein Problem liegt... :-(

Dieses Problem mit dem fehlenden Ton hatte ich übrigens auch nicht bei allen Gesprächen - das wechselte wild (und es gab auch ein paar Nummern - bei denen ging es nie)

noch einmal zu UDP: UDP kann man nicht NATen d.h. UDP 5060, 5070 5080 und 8000-8019 muss also (wenn Gemeinschaft im internen Netz ist und das SIP-Gateway draußen) direkt per Portforwarding auf die Anlage gegeben werden

Gruß

Matthias

[Patrick Baeumel]

Hallo Matthias,

 

toll, dass du dran bleibst an mir und meinem unangenehmen Problem ;-)

 

Ich habe jetzt nach dem Stichwort FritzBox die Gruppe durchsucht und auch viele Treffer, jedoch nirgends wirklich etwas vergleichbares zu meinem Thema gefunden und auch in keinem Post spezielle Infos über Port-Problem… (Evtl. habe ich es auch nur übersehen?)

 

Ggf. muss ich hier nochmals ergänzen:

Ich habe die Geminschaft als sog. „Internetrufnummer“ in der FritzBox angelegt; d.h. eigentlich genauso wie man dort einen SIP-Account eines Providers eintragen würde. Für die FritzBpx sollte Geminschaft damit eigentlich wirken wie ein ganz normaler SIP-Provider.

 

An der FritzBox angeschlossen ist ein Fritz-C4-DECT-Telefon, welchem ich die angelegte „Internetrufnummer“ der Gemeinschaft auch zugeordnet habe.

 

Aktuell wählt man am Fritz-C4-DECT-Telefon noch die *122#, um der FritzBox zu sagen „Hallo du; nimm mal den SIP-Account, der unter Kennung *122# in dir angelegt ist und mach was mit dem“. Dann wählt man die Nummer, was eigentlich bewirken sollte, dass die FritzBox sich mit dem SIP-Account in der Gemeinschaft verbindet und dem die gewählte Nummer übergibt.

 

Gemeinschaft sucht dann – nach meinem Verständnis - anhand der Outboundregeln welches Gateway (also die tatsächliche Providerverbindung) Sie machen soll und wählt Ihrerseits raus. Vom Prinzip läuft also doch der VOIP-Verkehr primär in und über die FritzBox.

 

Auf die FritzBox kann ich leider so ohne weiteres nicht verzichten.

Haben noch andere User erfolgreich eine Geminschaft hinter der FritzBox laufen und können evtl. Ihre Konfiguration mit mir/uns teilen?

 

Grüße,

Patrick

[Patrick Bäumel]

Hallo zusammen,

nachdem auch der private Hinweis eines Gruppenmitglieds doch einen STUN-Server in der FritzBox zu setzen keine Veränderung gebracht hatte, habe ich nun einen anderen Versuch gestartet und mich kurz bei Sipgate Trunk angemeldet.

Ergebnis:
Es klingelt hüben wie drüben; egal ob meine Mobilfunknummer oder die Festnetznummer meiner Tante angerufen wird und Gespäche klappen einwandfrei.
Und dies ohne weitere Änderungen an der FritzBox und deren nicht veränderlichen (SIP-)Routing, (SIP-)Port-Freigaben.

Tja das Problem ist nur:
Mindestens für Outbound-Telefonate in die Mobilfunknetze (und eigentlich wg. Flatrate) national und local möchte ich easybell nutzen.

Die Frage ist nun:
Warum tut es bei Sipgate; bei easybell aber nicht?

Grüße,
Patrick

[Patrick Bäumel]

Wir nähern uns ganz, ganz langsam der "trapsenden Nachtigall":
Unter http://wiki.freeswitch.org/wiki/RTP_Issues#Carrier_Info sind ja einige der Probleme - insbesondere die mit Sonus-Gegengeräten ;-) - aufgeführt.

Unter anderm steht dort weit oben:

"Known to support exactly 729 with rfc2833 OR 711u with DTMF inband.
If you're using FreeSWITCH then you'll be stuck using 711u (PCMU) with DTMF inband.Code hier eingeben..."

Ich habe dann einfach mal spaßeshalber die Einstellung "outbound-codec-prefs" auf alleine den Wert "PCMU" gesetzt und mit dieser Einstellung ist z.B der Festnetzanschluss meiner Tante endlich erreichbar.
Ebenso musste ich die FritzBox in Sachen DTMF auf Inband setzen, damit DTMF-Auswahlmenüs funktionieren.
(Was ich allerdings nicht versteh in den Freeswitch-Logfiles sieht es so aus, also ob weiterhin mit PCMA telefoniert werden würde.)

Leider bleibt bei meinem Handy das Ergebnis noch recht unverändert; hier kommt die Verbindung manchmal zu Stande und manchmal nicht.

Ich habe da noch eine Idee, dazu benötigte ich aber nochmals Hilfe:
Was genau wird von der Gemeinschaft in dem SDP-Block unter "o=" bzw. "s=" angezeigt?

Beispiel:
2014-02-09 13:56:33.090646 [DEBUG] sofia.c:5605 Duplicate SDP
v=0
o=- 149674837 0 IN IP4 212.172.97.124
s=Cisco SDP 0
c=IN IP4 212.172.97.124
t=0 0
m=audio 33944 RTP/AVP 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=X-sqn:0
a=X-cap: 1 image udptl t38
a=rtcp:33945

Die IP 212.172.97.124 gehört zu easybell (sip.easybell.de zeigt darauf).
Aber steht das unter "s=" angegebene Cico Equipment nun auch bei easybell oder evtl. schon beim Endempfänger?

Rufe ich nämlich die Telefonnummer meines Arbeitgebers an, dann kommt als SDP-Ausgabe:
2014-02-09 14:53:11.550657 [DEBUG] sofia.c:5605 Duplicate SDP
v=0
o=hiQ9200 1164190368 1780613153 IN IP4 212.172.97.124
s=Phone Call via hiQ9200 SIPCA
c=IN IP4 212.172.97.124
t=0 0
m=audio 39214 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=fmtp:8 vad=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 8 101
a=cpar: a=rtpmap:8 PCMA/8000
a=cpar: a=fmtp:8 vad=no
a=cpar: a=rtpmap:101 telephone-event
a=cpar: a=fmtp:101 0-15
a=rtcp:39215

Die IP 212.172.97.124 ist gleich und gehört easybell; unter "s=" ist nun aber eine "hiQ9200" genannt; nun ja und das ist die Siemens-Telefonanlage meines Arbeitgebers.

Wenn nun aber unter "s=" jeweils die Hardware des Endempfänger steht, dann gilt vielleicht ein anderer Hinweis aus dem Freeswitch-Wiki zum Sonus-Problem:
"If you are going through a provider who uses Sonus only as an SBC and not in your media path FreeSWITCH may incorrectly identify your call as going through Sonus and actually corrupt your media stream's DTMF. You can override FreeSWITCH's auto-detection of end-user agents with a flag in your sip_profiles/ profiles. Just add:

<param name="auto-rtp-bugs" value="clear"/>"

Wo müsste ich den entsprechenden Parameter "auto-rtp-bugs" setzen? Geht dies über das Web-GUI?

Grüße,
Patrick

[AP]

Hallo,

habe zwar kein easybell, hatte aber ein ähnliches Phänomen und konnte es in den /gs_parameters mit der Einstellung send_ringing_to_gateways true beseitigen. Vielleicht hilft dir das.

Am Dienstag, 4. Februar 2014 02:03:03 UTC+1 schrieb Patrick Bäumel:

[Sascha Daniels]

Hi.

Am 17.02.14 10:12, schrieb AP:

Hallo,

habe zwar kein easybell, hatte aber ein ähnliches Phänomen und konnte es in den /gs_parameters mit der Einstellung send_ringing_to_gateways true beseitigen. Vielleicht hilft dir das.

Der Parameter ist nur für die andere Richtung. Er hilft, wenn ein externer Anrufer kein Freizeichen bekommt. Das liegt daran, dass Freeswitch ein Ringing und dann ein Progress schickt. Da haben manche Provider und Gateways ein Problem damit.

Gruss

            Sascha

-- 
Sascha Daniels
s...@alternative-solution.de
www.alternative-solution.de