ich habe mit einem SIP-Trunk aus der Türkei das Problem, dass der Trunk zwar registered ist, aber der peer regelmäßig für ein paar Sekunden/manchmal Minuten unavailable bzw. laut CLI unreachable ist. Ich habe bereits versucht per CLI zu debuggen “pjsip set history on/off” und letztendlich die history auch analysiert, allerdings hilft mir das Ergebnis des logs nicht weiter. Es ist gelegentlich ein “trying” und “unauthorized” zu finden, aber in den Details stand nichts nützliches.
Der Provider schrieb dazu, dass es Netzwerk-Probleme unser pascom.cloud sind, allerdings funktionieren alle anderen SIP-Trunks problemlos. Jedoch gibt es wohl auch ein ähnliches Problem mit dem Telekom-SIP-Trunk, wenn ich das richtig in Erinnerung habe.
Habt ihr eine Idee, woran es liegen könnte, wenn ständig der peer verloren geht?
das Telekom Problem ist hier nicht ähnlich und anderer Natur. Im Gegensatz zum Register findet der qualify via SIP OPTIONS häufiger statt. Sobald hier ein Paket nicht beantwortet wird ist das Peer bzw der Endpoint unreachable. Wenn die RTP Streams zum gleichen Host gehen und hier kein Packetloss zu verzeichnen ist, halte ich die Verbindung nicht für das Problem. Zu unseren europäischen Trunks haben wir keinerlei Probleme, die Cloud ist ausreichend angebunden. Wenn ist das Problem nicht am Gegenbüber liegt wären eher die Übergabepunkte/Vermittlungsplattformen zwischen den Providern zu prüfen (ich denke nicht das es an den CIX zu suchen ist).
unreachable heißt in meinem Fall allerdings auch, dass eingehende und ausgehende Gespräche nicht funktionieren. Wenn dies ein normales Verhalten ist und ich beispielsweise das qualify ausschalte, dann würde der Trunk doch trotzdem nicht funktionieren, oder?
wenn eingehende nicht funktionieren ob wohl man noch registered ist, dann liegt es am gegenüber oder einem beteiligten Router dessen UDP Connection ausgelaufen ist und deswegen nicht “zurückgeNATed” werden kann. Falls der Provider SIP TCP unterstützt wäre das ein Versuch wert (transport=tcp).
Wenn du das Qualify ausschaltest wird der ausgehende Invite in jedem Fall versendet, es kann bei längerem “nicht telefonieren” über den Trunk aber zu oben erwähnten UDP Connection Timeout auf einer der beteiligten Router/Firewalls kommen.