Probleme mit Easybell SIP Trunk

  • Hi alle,


    wir betreiben seit ca. 1,5 Jahren eine Starface VM (derzeit mit Version 6.4.3.34) an einem SIP Trunk von Easybell. Wir haben recht viele
    "Vieltelefonierer" und es gab in der Vergangenheit keine (nennenswerten) Probleme mit dem Setup.


    Aber seit ca. 14 Tagen haben wir das Problem, dass immer wieder einige eingehende Anrufe nicht bei uns ankommen. Ich sehe im
    "full" Log in solchen Fällen keinen einkommenden Anruf. Wenn der Anrufer von einem Handy aus anruft, kommt die Ansage "der
    Teilnehmer ist derzeit nicht erreichbar".


    Bei Easybell wurde mir gesagt, dass im Log zu sehen ist, dass die Starface recht häufig nicht erreichbar sei und der Call dann nicht
    vermittelt werden kann. In den Staface Logs sehe ich dazu aber gar nichts.
    Ich habe mal mit asterisk -rvvvv versucht den Peer Status zu beobachten. Hier konnte ich ebenfalls keine Auffälligkeiten sehen.
    sip show peer xxxx sagt mir immer "Status OK (xx ms)" wobei es da Schwankungen zwischen 10 und 120ms gibt.


    Probleme auf Netzwerkebene (Anbindung über Colt Glasfaster mit statischer/dedizierter IP für die Starface - aber hinter einem NAT GW)
    schließe ich derzeit aus (ping sagt ca. 5.5ms RTT zu sip.easybell.de, keine für mich messbaren Paketverluste).


    Die Anbindung des SIP Trunks wurde über das verifizierte easybell Providerprofil realisiert. Der Easybell Support meinte, ich solle
    doch mal den "SIP Session Timer" und/oder RTP Keepalive ändern. Nun ist mein Wissen über SIP etwas begrenzt, aber der RTP
    Keepalive ist m.E. nur für aktive oder gehatene Gespräche relevant und nicht für den Status des Peers, oder?
    SIP Session Timer klingt da schon interessanter, aber wo finde ich den, und wie stellt man den ein?


    Hat jemand derzeit ähnliche Probleme mit Easybell?


    Im übrigen haben wir von Easybell eine Wartungsankündigung (Upgrade der Telefonie-Infrastruktur, Leistungsfähigerer SBC Server)
    für den 30. Mai 2018 erhalten. Das entspricht doch ziemlich genau dem Zeitpunkt an dem unsere Probleme begannen. Bei Easybell
    versichert man mir jedoch "hoch und heilig" das es da keinen Zusammenhang geben könne...


    Was nun? Hat da jemand eine Idee? Bin für jeden Tipp dankbar.


    Gruß
    Thomas

  • Hallo Thomas


    Wir haben gleiche Probleme, aber nicht mit der Easybell, sondern mit der Peoplefone Deutschland.


    Konkret besteht das Problem, seit dem wir dort das Starface Update gefahren haben.
    Wir nutzen auch das Offizielle Profil der Peopelfone.


    Die Logfiles der Peoplefone zeigen 408 (Request Timeout), auf der Starface sehe ich nichts, weder in den Logfiles, noch mit dem Wireshark.


    Es kann sein, dass es 2-3 Stunden läuft, dann 30 Minuten "Teilnehmer nicht erreichbar" kommt, dann geht es wieder den Rest vom Tag.


    Darauf hin haben wir mit dem PRTG Monitor das Netz überwacht ob irgendwelche Auffälligkeiten gibt. Garnichts.


    Wir gingen ursprünglich von einem Routing-Problem aus, das kann aber nach mehreren Prüfungen auch nicht die Ursache sein.
    Ein Ticket dazu ist von unserer Seite offen ( [Call#6905787]), falls wir dort ein Feedback erhalte, welches von Nutzen wäre, würde ich das hier noch Posten.


    MfG


    Fabian

  • Hallo Fabian,


    vielen Dank für das Feedback. Ich habe vorhin auch einen Starface Call aufgemacht. Das die Problematik mit dem letzten Starface Update
    zusammenhängt (auf 6.4.3.34) hatte ich zwar auch schon in Erwägung gezogen, halte das aber bei uns für nicht unbedingt sehr wahrscheinlich.
    Wir hatten Diesen Update bereits Mitte März gemacht und die Probleme gibt es erst seit Ende Mai / Anfang Juni.


    Aber ich werde nochmal die Meldungen der Nutzer genauer ansehen und prüfen, ob es da einen Zusammenhang mit dem Update gibt.


    Gruß
    Thomas

  • Hallo Thomas,


    unser 2nd Level Support würde sich den Fall gerne anschauen. Kannst Du uns die Ticketnummer oder die Kundennummer per Direktnachricht zukommen lassen?


    Grüße
    Stefan von easybell

  • Hallo,


    wir haben leider nach wie vor erhebliche Probleme mit dem Easybell Trunk. Daher habe ich das SIP Debugging auf der Starface mal eingeschaltet und die letzten Tage
    laufen lassen. Mir ist hier folgendes aufgefallen:


    Die Starface versucht ca. alle 10min (genauer: alle 585 Sekunden) sich neu zu registrieren (unsere Tel-Nr und unsere IPs habe ich geändert, 195.185.37.60 ist sip.easybell.de):


    REGISTER sip:sip.easybell.de SIP/2.0
    Via: SIP/2.0/UDP 1.2.3.4:5060;branch=z9hG4bK373da84f;rport
    Max-Forwards: 70
    From: <sip:004933445566@sip.easybell.de>;tag=as1754381c
    To: <sip:004933445566@sip.easybell.de>
    Call-ID: 233197827de1d3416d8a2a9964ac47a3@[::1]
    CSeq: 214 REGISTER
    User-Agent: STARFACE PBX
    Authorization: Digest username="004933445566", realm="sip.easybell.de", algorithm=MD5, uri="sip:sip.easybell.de", nonce="WyhMNFsoSwiD9y12v2SQgarHDV4sQyKm", response="267f0638873075c9113bf674576bd6bc"
    Expires: 600
    Contact: <sip:004933445566@1.2.3.4:5060>
    Content-Length: 0


    Und erhält von Easybell ein "Unauthorized" zurück:


    <--- SIP read from UDP:195.185.37.60:5060 --->
    SIP/2.0 401 Unauthorized
    Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK373da84f;rport=5060
    [....]


    Daraufhin versucht die Starface das gleich nochmal (in der gleichen Sekunde):
    REGISTER sip:sip.easybell.de SIP/2.0
    Via: SIP/2.0/UDP 1.2.3.4:5060;branch=z9hG4bK7fb2cc0a;rport
    Max-Forwards: 70
    From: <sip:004933445566@sip.easybell.de>;tag=as1754381c
    To: <sip:004933445566@sip.easybell.de>
    Call-ID: 233197827de1d3416d8a2a9964ac47a3@[::1]
    CSeq: 215 REGISTER
    User-Agent: STARFACE PBX
    Authorization: Digest username="004933445566", realm="sip.easybell.de", algorithm=MD5, uri="sip:sip.easybell.de", nonce="WyhOfVsoTVGjRPiS7E89xrgaX8eBAD7J", response="5174e180cb5cf80c4d7f982cd35a80aa"
    Expires: 600
    Contact: <sip:004933445566@1.2.3.4:5060>
    Content-Length: 0


    Und diesmal klappt das dann auch:
    <--- SIP read from UDP:195.185.37.60:5060 --->
    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK7fb2cc0a;rport=5060
    From: <sip:004933445566@sip.easybell.de>;tag=as1754381c
    To: <sip:004933445566@sip.easybell.de>;tag=1d24a28a0bded6c40d31e6db8aab9ac6.d6fc
    Call-ID: 233197827de1d3416d8a2a9964ac47a3@[::1]
    CSeq: 215 REGISTER
    P-NGCP-Auth-IP: 195.185.214.173
    P-NGCP-Auth-UA: STARFACE PBX
    Server: Sipwise NGCP Proxy 5.X
    Contact: <sip:004933445566@10.0.0.1:5060>;expires=517
    Content-Length: 0


    Was mich aber sehr wundert, ist der von Easybell zurückgelieferte "expires" Wert von 517 (Sekunden - wie ich vermute). Die Starface hatte bei der Registrierung 600 Sekunden angegeben.
    Ich vermute nun, dass genau diese Diskrepanz das Problem ist. Ich habe das mal über den Tag verfolgt und tatsächlich sind die von easybell zurückgelieferten Werte immer unterscheidlich.
    Sie schwanken zwischen 420 und 598 Sekunden. Dass ist also im Extremfall ein Unterschied von 180 Sekunden (600 Sekunden Starface, 420 Sekunden Easybell). Ich vermute, wenn dann
    in diesem Zeitraum ein Anruf für uns bei Easybell ankommt, wird der nicht vermittelt....


    Vielleicht hat ja jemand mehr Ahnung von diesen Timern als ich und kann dazu was kompetentes sagen. Falls meine Vermutung stimmt: wie kann man das beheben? Wo kann man
    überhaupt diesen Timer einstellen? Es scheint mir auch nicht so ohne weiteres Zielführend diesen Timer einseitig (in der Starface) zu erhöhen. Dadurch wird man ja die Diskrepanz
    erstmal noch nicht los. Es wäre viel wichtiger rauszufinden, warum sich die Starface und Easybell "nicht einig" sind....


    Gruß
    Thomas

  • Hallo zusammen,


    wir haben seit neuestem das Probleme mit easybell und der Starface 6.5.0.30 das wir nach ca. 7-10 zwar den angerufenen noch hören aber er uns nicht mehr.
    Könnte das ggf. auch damit zusammenhängen?

    Beste Grüße,


    Manuel

  • Hallo alle,


    nach über einer Woche debuggen und 2 Supportcalls (einer bei Starface, einer bei Easybell) konnten wir das Problem lösen. Hier die Zusammenfassung.


    Der Grund für die Nichterreichbarkeit ist ohne Zweifel die Diskrepanz der "expires" Werte beim SIP REGISTER und der entsprechenden Antwort von Easybell (s.o.).
    Die Starface geht auf den von Easybell vorgeschlagenen, abweichenden "expires" Wert nicht ein und bleibt bei ihren 600 Sekunden. Dadurch entstehen Diskrepanzen
    von bis zu 3 Minuten. Anrufe, die während dieser Zeit eingehen, werden von Easybell nicht zur Starface vermittelt.


    Hier kam die erste Frage auf: Warum schlägt Easybell überhaut einen anderen "expires" Wert vor? Antwort: das ist unklar, aber letztlich auch nicht relevant. Das Verhalten
    von Easybell ist vielleicht etwas "komisch" aber laut Standard offenbar legitim. Die Starface müsste eigentlich darauf eingehen und den expires Timer anpassen.


    Sind wir gleich bei der nächsten Frage: Warum geht die Starface darauf nicht ein: Hier muss man etwas den Standard bemühen. Die Starface darf bzw. soll
    nur dann auf den expire Wert eingehen, wenn das "Contact" Feld im SIP REGISTER und im SIP Antwort Paket identisch ist. Das ist aber in unserem Fall leider
    nicht so:


    Starface REGISTER:Contact: <sip:004933445566@1.2.3.4:5060>
    Easybell Antowort: Contact: <sip:004933445566@10.0.0.1:5060>;expires=517 (man beachte die unterschiedlichen IPs)


    Im SIP Register Paket hat die Starface unsere öffentliche IP eingetragen (wg. globaler Einstellung "Hinter NAT->ja"). Das
    Antwortpaket von Easybell enthält aber die private IP unserer Starface. Daher verhält sich die Starface insofern richtig, als
    dass der von Easybell gelieferte expires Wert ignoriert wird. Das verursacht dann das von uns beobachtete Problem.


    An dieser Stelle habe dann mal testweise die Einstellung "Hinter NAT" auf "nein" gesetzt. Jetzt schickt die Starface
    bei den REGISTER Paketen im Contact die private IP raus. Da in den Antworten auch die Private IP steckt, akzeptiert
    die Starface dann auch den geänderten expires Wert und das Problem ist unmittelbar behoben. Man kann das im "full"
    log der Starface bei eingeschlatetem SIP debugging dann auch an folgenden Einträgen erkennen:


    [Jun 22 17:13:58] NOTICE[32542] chan_sip.c: Outbound Registration: Expiry for sip.easybell.de is 430 sec (Scheduling reregistration in 415 s)


    Leider verursacht diese geändete globale Einstellung der Starface bei uns aber andere Schwierigkeiten und es bleibt
    die Frage:


    Warum schickt Easybell in den Antworten auf die SIP REGISTER Pakete überhaupt die private IP unserer Starface im Contact
    Feld? Woher kennt Easybell diese IP überhaupt? Das wäre dann auch die Masterfrage mit doppelter Punktzahl....


    Und die Antwort ist: Das macht unsere Cisco! Yeah... doppelte Punktzahl!!! Was ein Schrott! Cisco hat offenbar seit IOS 15x
    für 1:1 NAT Abbildungen ALG ("application-layer gateway) per default aktiviert. Das gilt _mindestens_ für DNS und für SIP Pakete.
    Absolut Traumhaft... Ohne das man irgendwas einstellt manipuliert die Cisco den Inhalt (Payload !!!) von DNS und SIP Paketen
    und tauscht die private gegen die öffentliche IP aus. Ausschalten mit:


    no ip nat service sip udp port 5060
    (und zur Sicherheit gleich auch für tcp):
    no ip nat service sip tcp port 5060


    Und genau an dieser Stelle waren alle unsere Probleme verschwunden. Offene Frage wäre noch: die Cisco Konfiguration
    hat sich in den letzen 2 Jahren nicht verändert. Warum fällt das Problem erst jetzt auf? Ich vermute, dass Easybell Änderungen
    an der Infrastruktur vorgenommen hat, die "strengere" expires Timer zur Folge haben. Früher gab es möglicherweise
    diese Diskrepanz zwischen den Expires Werten nicht und das Fehlerbild ist dadurch in der Vergangenheit gar nicht
    entstanden.


    Gruß
    Thomas

  • Vielen Dank dafür, dass Du das nach Lösung des Problems noch so ausführlich zusammenfasst! Das wünsche ich mir öfters hier in den Foren... ;)


    Grüße,


    d i r k

    Viele Grüße


    d i r k

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!