23.05.2025, aktualisiert 30.05.2025

1488

Problem Cisco 926 4P VoiP SnomD713 SIP eingehen ausgehend keine Telefonie und Uhrzeit Problem

Hallo,

ich störe nur ungern aber habe ein Problem mit nem Cisco ROuter und SNOM D713 Telefon was betrieben werden soll.

Ich habe eine Zone Based Firewall und die Config kann ich euch geben genauso wie die Ausgabe der CLI das geblockt wird.
Könnt Ihr mir weiterhelfen weil ich nicht weiterkomme.

https://administrator.de/tutorial/cisco-800-900-isr1100-router-konfiguration-mit-xdsl-kabel-ftth-anschluss-und-vpn-179345.html

In der obigen Anleitung konnte ich nicht genau herausfinden was ich machen muss aber SIP ist grundlegend nicht geblockt oder liege ich falsch?

Gleichzeitig habe ich beim hochladen der letzten Firmeware festgestellt dass die Zeit nicht passt , aber mit den Befehlen welche ich ausprobiert habe konnte ich das Problem nicht beheben und die Zeit stimmt immer noch nicht wäre toll wenn mir auch da jmd. helfen könnte.

Hier die Config

*May 17 12:06:45: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) -  dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:06:46: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) -  dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:06:47: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) -  dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:06:49: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) -  dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:06:53: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) -  dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:06:57: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) -  dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:07:01: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) -  dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:07:05: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) -  dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:07:09: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) -  dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:07:13: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) -  dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT
*May 17 12:07:17: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) -  dropping udp session 192.168.100.153:42251 externe IP:5060 on zone-pair LOKAL-INTERNET class LOKAL-ERLAUBT


Cisco_Router#sh ver
Cisco IOS Software, C900 Software (C900-UNIVERSALK9-M), Version 15.9(3)M11, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2025 by Cisco Systems, Inc.
Compiled Thu 20-Mar-25 03:13 by mcpre

ROM: System Bootstrap, Version 15.8(3r)M0b, RELEASE SOFTWARE (fc1)

Cisco_Router uptime is 6 hours, 42 minutes
System returned to ROM by power-on
System image file is "flash:c900-universalk9-mz.SPA.159-3.M11.bin"  
Last reload type: Normal Reload
Last reload reason: power-on


This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

Cisco C926-4P (revision 1.0) with 994825K/53750K bytes of memory.
Processor board ID FGL2551L05S
1 DSL controller
1 Ethernet interface
5 Gigabit Ethernet interfaces
1 ATM interface
1 Virtual Private Network (VPN) Module
256K bytes of non-volatile configuration memory.
1900544K bytes of SD Flash flash (Read/Write)


License Info:

License UDI:

-------------------------------------------------
Device#   PID                   SN
-------------------------------------------------
*1        C926-4P               SERIENNNUMMER


Technology Package License Information for Module:'c900'  

------------------------------------------------------------------------
Technology    Technology-package                  Technology-package
              Current              Type           Next reboot
------------------------------------------------------------------------
ipbase        ipbasek9             Permanent      ipbasek9
security      securityk9           Permanent      securityk9
appx          None                 None           None

Configuration register is 0x2102

Cisco_Router#show conf
Using 6373 out of 262144 bytes
!
version 15.9
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec
service timestamps log datetime localtime
service password-encryption
!
hostname Cisco_Router
!
boot-start-marker
boot system flash:c900-universalk9-mz.SPA.159-3.M11.bin
boot-end-marker
!
!
enable secret 9 XXXXXX
!
aaa new-model
aaa local authentication attempts max-fail 3
!
!
aaa authentication login default local
!
!
!
!
!
!
aaa session-id common
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
!
!
!
!
no ip source-route
no ip gratuitous-arps
!
!
!
ip dhcp excluded-address 192.168.100.1 192.168.100.149
ip dhcp excluded-address 192.168.100.200 192.168.100.254
ip dhcp excluded-address 172.16.100.1 172.16.100.149
ip dhcp excluded-address 172.16.100.200 172.16.100.254
!
ip dhcp pool Lokal
 network 192.168.100.0 255.255.255.0
 default-router 192.168.100.254
 dns-server 192.168.100.254
 domain-name mario.domain
!
ip dhcp pool Gastnetz
 network 172.16.100.0 255.255.255.0
 default-router 172.16.100.254
 dns-server 172.16.100.254
 domain-name mario.domain
!
!
!
ip domain name mario.domain
ip cef
ipv6 unicast-routing
ipv6 dhcp pool DHCPv6
!
ipv6 cef
!
multilink bundle-name authenticated
!
!
!
license udi pid C926-4P sn FGL2551L05S
!
!
username admin privilege 15 secret 9 XXXXXX
!
redundancy
!
!
!
!
!
controller VDSL 0
 firmware filename flash:c900_VA_A_39x3_B_39x3_26d.bin
!
!
class-map type inspect match-any LOKAL-ERLAUBT
 match protocol http
 match protocol https
 match protocol dns
 match protocol pop3s
 match protocol imaps
 match protocol smtp
 match protocol sip
 match protocol sip-tls
 match protocol rtsp
 match protocol ftp
 match protocol ftps
 match protocol ssh
 match protocol ntp
 match protocol tcp
 match protocol udp
 match protocol icmp
class-map type inspect match-any GAST-ERLAUBT
 match protocol http
 match protocol https
 match protocol dns
 match protocol ntp
class-map type inspect match-all IPsec_VPN
 match access-group name ISAKMP_IPSEC
class-map type inspect match-any ROUTER-PROTOCOLS
 match class-map IPsec_VPN
 match protocol tcp
 match protocol udp
 match protocol icmp
!
policy-map type inspect LOKAL-INTERNET-POLICY
 description Traffic Lokales LAN zum Internet
 class type inspect LOKAL-ERLAUBT
  inspect
 class class-default
  drop
policy-map type inspect ROUTER-INTERNET-POLICY
 description Traffic Router zum Internet
 class type inspect ROUTER-PROTOCOLS
  inspect
 class class-default
  drop
policy-map type inspect GAST-INTERNET-POLICY
 description Traffic Gast zum Internet
 class type inspect GAST-ERLAUBT
  inspect
 class class-default
  drop
policy-map type inspect INTERNET-ROUTER-POLICY
 description Traffic Internet zum Router
 class type inspect IPsec_VPN
  pass
 class class-default
  drop
!
zone security LOKAL
zone security GAST
zone security INTERNET
zone-pair security LOKAL-INTERNET source LOKAL destination INTERNET
 service-policy type inspect LOKAL-INTERNET-POLICY
zone-pair security GAST-INTERNET source GAST destination INTERNET
 service-policy type inspect GAST-INTERNET-POLICY
zone-pair security INTERNET-ROUTER source INTERNET destination self
 service-policy type inspect INTERNET-ROUTER-POLICY
zone-pair security ROUTER-INTERNET source self destination INTERNET
 service-policy type inspect ROUTER-INTERNET-POLICY
!
!
!
!
!
!
!
!
!
!
interface ATM0
 no ip address
 shutdown
 no atm ilmi-keepalive
!
interface Ethernet0
 no ip address
!
interface Ethernet0.7
 description VDSL Internet Verbindung - VLAN 7 tagged
 encapsulation dot1Q 7
 pppoe enable group global
 pppoe-client dial-pool-number 1
!
interface GigabitEthernet0
 no ip address
!
interface GigabitEthernet1
 no ip address
!
interface GigabitEthernet2
 no ip address
!
interface GigabitEthernet3
 description Gastnetz
 no ip address
 no cdp enable
!
interface GigabitEthernet4
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface Vlan1
 description Lokales LAN
 ip address 192.168.100.254 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 zone-member security LOKAL
 ip tcp adjust-mss 1448
 ipv6 address provider-v6-prefix ::1:0:0:0:1/64
 ipv6 enable
 ipv6 nd other-config-flag
 ipv6 dhcp server DHCPv6
!
interface Vlan2
 description Gastnetz
 ip address 172.16.100.254 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 zone-member security GAST
 ip tcp adjust-mss 1448
 ipv6 address provider-v6-prefix ::2:0:0:0:1/64
 ipv6 enable
 ipv6 nd other-config-flag
 ipv6 dhcp server DHCPv6
!
interface Dialer0
 description DSL Internet Interface
 mtu 1488
 ip address negotiated
 ip access-group bockext in
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nat outside
 ip virtual-reassembly in
 zone-member security INTERNET
 encapsulation ppp
 dialer pool 1
 dialer-group 1
 no cdp enable
 ipv6 address autoconfig default
 ipv6 enable
 ipv6 nd autoconfig default-route
 no ipv6 redirects
 no ipv6 unreachables
 ipv6 dhcp client pd provider-v6-prefix rapid-commit
 ipv6 verify unicast reverse-path
 ppp authentication pap callin
 ppp pap sent-username DSL@PROVIDER.DE password 7 XXXXXX
 ppp ipcp dns request
 ppp ipcp mask request
 ppp ipcp route default
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
!
ip dns server
ip nat inside source list 101 interface Dialer0 overload
!
ip access-list extended ISAKMP_IPSEC
 permit udp any any eq isakmp
 permit udp any any eq non500-isakmp
 permit esp any any
ip access-list extended blockext
 remark offene TCP Verbindungen dr
 remark offene TCP Verbindungen durchlassen
 permit tcp any any established
 remark DNS Port beide Protokolle, blockieren
 deny   tcp any any eq domain
 deny   udp any any eq domain
 remark Rest erlauben
 permit ip any any
!
!
!
tftp-server flash:/firmware/vadsl_module_img.bin
access-list 101 permit ip 192.168.100.0 0.0.0.255 any
access-list 101 permit ip 172.16.100.0 0.0.0.255 any
!
!
!
control-plane
!
banner motd ^CCCC
LOGIN AUF DIESEN ROUTER OHNE GENEHMIGUNG STRAFBAR AUCH JEG: VERSUCH . ALLES ANDE                                                     RE AUCH!!!
NO LOGIN IS ALLOWED OR USING OF THIS ROUTER!
^C
!
line con 0
line vty 0 4
 transport input none
!
scheduler allocate 20000 1000
!
end

Gruß Mario

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Kommentar vom Moderator colinardo am 24.05.2025 um 07:32:59 Uhr

Konfiguration in Codetags gesetzt.

Content-ID: 673009

Url: https://administrator.de/forum/problem-cisco-926-4p-voip-snomd713-sip-eingehen-ausgehend-keine-telefonie-und-uhrzeit-problem-673009.html

Ausgedruckt am: 14.07.2025 um 06:07 Uhr

32 Kommentare

Neuester Kommentar

Moin Mario,

vorab: könntest Du Deine Config bitte über die Beitrag bearbeiten Funktion in CODE-Tags setzen, das erhöht die Lesbarkeit erheblich und man kann Zeilennummern in der Antwort angeben.

Zu Deinem Telefon(ie)problem: Welche Telefonanlage oder VoIP-Anbieter kommt zum Einsatz? Oder bist Du noch immer bei o2 und versuchst dort die Telefonie im D713 anzudocken? Steht die TK-Anlage (wenn vorhanden) extern oder im internen Netz.
Zusätzlich mal auf der Weboberfläche des Snoms ins Logfile schauen, vielleicht schlagen auch bereits die SIP REGISTER Anfragen fehl (Logfile (auszugsweise) ggf. dann mal hier posten).

Ich vermute es gibt ein Problem mit der RTP-Übertragung. Aber dafür wäre ein Paketmitschnitt hilfreich, da kann man besser sehen, was genau passiert (geblockt wird).

Im Cisco Forum gibt es einige Einträge mit dem gleichen Problem: community.cisco.com/t5/network-security/zbfw-quot-sip-protocol-v ...

Einige FW-Versionen sind wohl buggy in Bezug auf SIP mit aktivierter deep packet inspection.

Gruß

cykes

aber SIP ist grundlegend nicht geblockt oder liege ich falsch?

Richtig, du liegst da keineswegs falsch!
Kannst du ja auch an deiner eigenen Class Map LOKAL-ERLAUBT für dein lokales LAN immer selber sehen. Am Ende mit match protocol tcp und udp lässt du ja grundsätzlich ALLES an TCP und UDP basierten Protokollen durch!
Alles was zusätzlich noch protokollspezifisch angegeben ist wird auch auf den UDP und TCP Port bezogen noch genauer untersucht. Das ist also alles OK.
Als Vergleich dazu kannst du dir die Class Map GAST-ERLAUBT für dein Gastnetz ansehen. Gäste dürfen bei dir lediglich mit dem Browser arbeiten, DNS Requests senden und NTP Zeitserver befragen. Ping, VoIP und auch alles andere ist den Gästen verboten.

SIP Thematik:
Sehr hilfreich ist es in dem Falle einmal ein freies VoIP Softphone auf dem PC zu installieren wie Phoner oder Phone Lite:
phoner.de/index.htm
lite.phoner.de/index_de.htm
Das Softphone konfigurierst du dann mit deinem SIP User/Pass und SIP-Server Credentials und kannst damit aktiv testen. Auf dem gleichen PC kannst du dann parallel einen Wireshark Sniffer bei Bedarf laufen lassen und dir den SIP Prozess einmal genau ansehen.
Zusätzlich führt die Phoner Software ein Log was etwaige Fehler und Probleme immer mitloggt.

Manche VoIP Endgeräte verhalten sich nicht SIP RFC Standard konform und "mögen" das mit der ZFW und der spezifischen SIP und RTP Inspection aktivierte Voice Application Gateway nicht, so das es zu den o.a. SIP Format Fehlermeldungen und Drops kommt weil die Firewall einen Angriff vermutet.
In dem Falle ist es dann immer hilfreich zuerst testweise die beiden SIP "match" Kommandos aus der Class Map zu entfernen und nur RTSP zu belassen.
Die VoIP Protokoll Inspection wir dann weniger restriktiv und rein über die globale TCP bzw. UDP Inspection gemacht. Damit verschwindet dann auch die Fehlermeldung im Log und natürlich auch das Droppen dieses Traffics in der Firewall.
Im Zweifel, sollte es wider Erwarten immer noch nicht klappen, kannst du ebenfalls den RTSP Eintrag weglassen und das auch global über die UDP Inspection machen lassen.
Damit sollte das Problem verschwinden.
Sofern deine VoIP Endgeräte einen Keepalive nutzen prüfe das der Keepalive Timer nicht größer als 30 Sek. gesetzt ist oder stelle im Endgerät SIP immer auf einem TCP Encapsulation ein und nicht UDP! Prüfe dort auch das symetrische RTP Ports verwendet werden! Das o.a. Verhalten ist in erster Linie ein Konfig Fehler des VoIP Endgerätes und nicht des Routers. In so gut wie allen dieser Fälle halten sich Hersteller nicht an den SIP RFC Standard was dann bei protokollspezifischer Inspection in solchen Error Meldungen resultiert.
Wie gesagt: Prüfe das Verhalten auch immer mit dem o.a. Softphone im Vergleich.
Das Tutorial hat in den Kommentaren ebenfalls einen Thread zu dieser Thematik!

NTP Thematik:
Du hast auf dem Router keinerlei NTP Konfig, so das der Router daran scheitert sich von irgendwo her eine korrekte Uhrzeit und Datum zu holen. Diese Konfig fehlt bei dir schlicht und einfach so das es erwartbar ist das du eine falsche Uhrzeit hast.

Wenn du die Uhrzeit aus dem Internet ziehst, dann lösen diese im Tutorial beschriebenen Kommandos dein selbstgemachtes NTP Problem im Handumdrehen:

ntp server de.pool.ntp.org source Dialer0
ntp update-calendar 

Das Source Interface kannst du natürlich ändern wenn du einen internen NTP Server im lokalen LAN betreibst.
Wenn dein Internet Provider eigene Zeitserver betreibt z.B. die Telekom D mit ntp1.t-online.de dann solltest du diese verwenden. Letztlich aber kosmetisch.
Der deutsche ntp.org Pool hat den Vorteil das sich dahinter mehrere NTP Server in einem Pool befinden. (Redundanz)
Ein show ntp status bzw. auch show ntp ass und show clock zeigt dir dann ob der Router eine korrekte NTP Zeitserver Verbindung aufgebaut hat und die korrekte Uhrzeit und Datum hat.

Weitere Punkte:

Konfigurations "Leichen" wie die ungenutzte und bei einer ZFW auch völlig überflüssige "blockext" Accessliste sollte man immer entfernen! Das verhindert Fehler und böse Side Effects.

Alles weitere erklärt dir, wie immer, das hiesige Cisco Tutorial.

Also schon einmal die Info dass das TSIp TElefon registriert ist abaer eingehend wie ausgehend keine Telefonie möglich ist eingehend ist das Telefon nicht erreichbar und ausgehend klingelt es es klingelt auch beim gegenüber aber wenn man abhebt höhrt man nichts und am VoiP Telefon sieht man auch nicht das abgehoben wurde.

@aqui was ist damit gemeint
"Weitere Punkte:
Konfigurations "Leichen" wie die ungenutzte und bei einer ZFW auch völlig überflüssige "blockext" Accessliste sollte man immer entfernen! Das verhindert Fehler und böse Side Effects." Welcher Eintrag ist gemeint damit? Anbieter ist O2. Das Telefon soll ausschließlich mit SIP Daten betrieben werden.

Zitat von @mariocisco:

Also schon einmal die Info dass das TSIp TElefon registriert ist abaer eingehend wie ausgehend keine Telefonie möglich ist eingehend ist das Telefon nicht erreichbar und ausgehend klingelt es es klingelt auch beim gegenüber aber wenn man abhebt höhrt man nichts und am VoiP Telefon sieht man auch nicht das abgehoben wurde.

Das sind weitere Indizien dafür, dass RTP nicht korrekt durchgeht, also Trace machen (geht auch auf einigen Snom Telefonen - das D713 kenne ich nicht aus eigener Anschauung) und mit Wireshark o.ä. auswerten.

@aqui was ist damit gemeint

"Weitere Punkte:
Konfigurations "Leichen" wie die ungenutzte und bei einer ZFW auch völlig überflüssige "blockext" Accessliste sollte man immer entfernen! Das verhindert Fehler und böse Side Effects."

Welcher Eintrag ist gemeint damit?

Er meint um die Zeile 339 (hab' Dein Zitat mal ein wenig umformatiert).

Anbieter ist O2. Das Telefon soll ausschließlich mit SIP Daten betrieben werden.

Sind die SIP-Daten direkt im Snom eingetragen? Welcher VoIP/SIP-Server steht da?
Ich meine mich erinnern zu können, dass es bei o2 da immer wieder Probleme mit SIP i.V.m. Fremdroutern gab. Ggf. wäre ein SBC hilfreich, wenn Du lokal keine VoIP-TK-Anlage hast. Ist das ein Privat- oder Geschäftskundenanschluss?

Gruß

cykes

TSIp TElefon

Was ist das? 🤔

abaer eingehend wie ausgehend keine Telefonie möglich ist

Ein paar Fragen dazu:

Hat das Telefon eine aktive SIP Session? Sprich ist es erfolgreich mit dem SIP Server verbunden? (Status Display)
Hast du parallel einmal das dir oben genannte kostenlose Softphone Phoner oder [https://lite.phoner.de/index_de.htm Phoner-Lite installiert mit den gleichen O2 SIP Credentials und damit einmal getestet? Wenn ja, welches Ergebnis? SIP Status im Logging etc.?
Hast du die beiden SIP match protocol Statements erst einmal testweise aus der Class Map Konfig entfernt? Ggf. auch das RTSP Statement? (Siehe dazu auch HIER in den Tutorial Kommentaren) Wie verhält sich das Telefon dann?
Wenn alle Stricke reissen deaktivierst du einmal testweise die ZFW Firewall komplett indem du auf allen 3 aktiven IP Interfaces die Zonen Zuordnung entfernst. Kommt dann eine SIP Session zustande mit Telefon und Softphone?

Fragen über Fragen....
Hier funktioniert ein Gemisch aus Auerswald Anlage, Cisco Telefonen und dem o.a. Softphone auf einem 886er, 896er, 926er und 1100er ohne jegliche Auffälligkeiten.
Vermutlich scheitert dein Telefon schon grundsätzlich an der O2 SIP Registrierung was dann auf falsche SIP Zugangsdaten schliessen lässt. Also einem Problem am Endgerät selber. Deshalb die Empfehlung testweise immer mit dem Softphone zu arbeiten, weil das eine deutlich bessere Troubleshooting Option durchs Logging hat.

was ist damit gemeint

OK, sorry wenn das unklar ausgedrückt war aber gerne nochmal etwas detailierter.
Auf deinem o.a. Router befindet sich eine ungenutzte und bei ZFW Betrieb damit auch sinnfreie Accessliste namens blockext!!
Da diese ACL völlig ungenutzt und damit nutzlos ist, weil sie nirgendwo zugewiesen ist solltest du diese besser mit no ip access-list extended blockext vollständig entfernen. Denn wozu sollte es Sinn machen so eine ungenutzte und damit überflüssige ACL (Leiche) in der Konfig zu behalten?

In Bezug auf IPv6 hat deine ZFW Konfig auch noch einen groben Fehler.

Es fehlt vollständig ein Regelwerk was DHCPv6 vom Internet Provider (O2) passieren lässt. Damit ist dann keine IPv6 Prefix Delegation und Adressvergabe vom Provider möglich. Als weitere Folge davon scheitert dann auch die ansonsten korrekt konfigurierte IPv6 Adressvergabe auf den internen LAN Interfaces.
Ein show ipv6 dhcp interface dialer0 sollte diesen Konfig Fehler belegen. Dort müsste die gescheiterte IPv6 Adressierung und v6 Prefix Delegation zu sehen sein.
Aber das ist jetzt erstmal nur ein Nebenkriegsschauplatz und hat mit dem eigentlichen Thread Thema VoIP nichts zu tun.
Details auch hier wie immer in den IPv6 Customizing Hinweisen für die ZFW Firewall im Cisco Tutorial.

@cykes es steht dort MEINE TElefonnummer@sip.alice-voip.de und es ist ein privat dsl anschluß

@aqui Frage:"Hat das Telefon eine aktive SIP Session? Sprich ist es erfolgreich mit dem SIP Server verbunden?" Antwort ja eine Verbindung ist da. Registriert mit dem SIP Server
Frage:"Hast du parallel einmal das dir oben genannte kostenlose Softphone Phoner oder Phoner-Lite installiert mit den gleichen O2 SIP Credentials und damit einmal getestet?"
Antwort: ja selbes Fehlerbild. Ein Ausgehend keine Telefonie.

Ok die Access List Leiche wird entfernt logs folgen.

Antwort: ja selbes Fehlerbild. Ein Ausgehend keine Telefonie.

Wie gesagt: Sehr wahrscheinlich scheitert zu 98% schon deine SIP Registrierung.

Für ein zielführendes Troubleshooting wäre jetzt einmal das Phoner Log sehr hilfreich.
Idealerweise indem du parallel einmal mit dem Wireshark dir die SIP Registrierung ansiehst. Dort kann man sofort sehen was Sache ist.
Wenn weder eingehend noch ausgehend Anrufe möglich sind ist es sehr wahrscheinlich das schon gar keine aktive SIP Session mit den Telefonen existiert.
Hast du auch einmal versucht den SIP Server sip.alice-voip.de zu pingen ob das möglich ist.

P.S.: Wenn zitieren dann bitte richtig so das man den Zitattext auch sauber erkennen kann!!

Zitieren von Kommentaren

Hier das Log

ich habe probiert rausgehend zu telefonieren:
"

May 24 13:29:53.239 [NOTICE] PHN: TPL: Socket 34 idle/connect timeout
May 24 13:29:53.491 [NOTICE] PHN: TPL: Socket 35 idle/connect timeout
May 24 13:29:59.815 [NOTICE] PHN: TPL: Socket 36 idle/connect timeout
May 24 13:30:05.212 [NOTICE] PHN: TPL: Socket 38 idle/connect timeout
May 24 13:30:06.084 [NOTICE] PHN: TPL: Socket 37 idle/connect timeout
May 24 13:30:11.742 [NOTICE] PHN: TPL: Socket 40 idle/connect timeout
May 24 13:30:13.625 [NOTICE] PHN: TPL: Socket 39 idle/connect timeout
May 24 13:30:16.775 [NOTICE] PHN: TPL: Socket 41 idle/connect timeout
May 24 13:30:18.777 [NOTICE] PHN: TPL: Socket 42 idle/connect timeout
May 24 13:30:25.021 [NOTICE] PHN: WEB: start pcap trace
May 24 13:30:27.525 [NOTICE] PHN: TPL: Socket 44 idle/connect timeout
May 24 13:30:28.036 [NOTICE] PHN: TPL: Socket 43 idle/connect timeout
May 24 13:30:40.752 [NOTICE] PHN: Fetching URL: file://xml/gui/state_settings.xml#...
May 24 13:30:43.925 [NOTICE] CSTA: csta_cid = 2
phone_cid2

May 24 13:30:44.122 [WARN  ] GUI: Minibrowser callback $/enter_number_fkey_list expecting vector result, but no vector callback defined
May 24 13:30:44.456 [NOTICE] MEDIA: PlayCall ssrc:654321 active: 0 use new channel
May 24 13:30:44.499 [WARN  ] GUI: Minibrowser callback $/enter_number_fkey_list expecting vector result, but no vector callback defined
May 24 13:30:45.045 [WARN  ] GUI: Minibrowser callback $/enter_number_fkey_list expecting vector result, but no vector callback defined
May 24 13:30:45.585 [NOTICE] MEDIA: PlayCall ssrc:654321 active: 0 use new channel
May 24 13:30:48.103 [WARN  ] GUI: Minibrowser callback $/enter_number_fkey_list expecting vector result, but no vector callback defined
May 24 13:30:48.943 [NOTICE] SIP: getInternalSdpFmts: Skipped Codec g723 is not supported for ptime of 20
May 24 13:30:49.125 [ERROR ] PHN: No reply for naptr lookup
May 24 13:30:49.140 [ERROR ] PHN: No reply for srv lookup
May 24 13:30:49.145 [ERROR ] PHN: No reply for srv lookup
May 24 13:30:50.252 [NOTICE] MEDIA: PlayCall ssrc:654321 active: 0 use new channel
May 24 13:30:56.513 [WARN  ] MEDIA: CallStats: 1491264231 not found
May 24 13:30:56.516 [ERROR ] MEDIA: Stream setup: invalid ssrc 1491264231, state off
May 24 13:30:56.572 [NOTICE] MEDIA: PlayCall ssrc:654321 active: 0 use new channel
May 24 13:31:25.470 [NOTICE] PHN: TPL: Socket 45 idle/connect timeout
May 24 13:31:26.654 [NOTICE] PHN: TPL: Socket 46 idle/connect timeout
May 24 13:31:28.365 [WARN  ] SIP: transaction_timeout udp: 1000005 (32000)
May 24 13:31:28.365 [ERROR ] SIP: transport error: 1000005 -> Udp:EXTERNEIP:5060
May 24 13:31:28.366 [NOTICE] SIP: Add dirty host: Udp:EXTERNE-IP:5060 (0 sec)
May 24 13:31:28.366 [ERROR ] SIP: request 1000005 destination invalid Udp:EXTERNE-IP:5060 e3ad3168c4ec-cpympxsg9oo8
May 24 13:31:28.366 [NOTICE] SIP: final transport error: 1000005 -> Udp:EXTERNE-IP:5060
May 24 13:31:28.368 [ERROR ] SIP: transport error 1000005: generating fake 599
May 24 13:31:28.382 [NOTICE] MEDIA: MediaIpc::rtpClose: RP1
May 24 13:31:28.387 [NOTICE] MEDIA: MediaIpc::rtpClose: RC1
May 24 13:31:28.390 [NOTICE] MEDIA: onRtpClose: RP1
May 24 13:31:28.391 [ERROR ] MEDIA: StopCall: failed to stop 1491264231
May 24 13:31:28.391 [NOTICE] MEDIA: onRtpClose: RC1
May 24 13:31:43.878 [NOTICE] PHN: TPL: Socket 47 idle/connect timeout
May 24 13:31:45.880 [NOTICE] PHN: TPL: Socket 48 idle/connect timeout
May 24 13:31:51.725 [NOTICE] PHN: TPL: Socket 49 idle/connect timeout
May 24 13:31:53.726 [NOTICE] PHN: TPL: Socket 50 idle/connect timeout
May 24 13:31:57.421 [DEBUG0] CFG: apply_value: log_level = '7', need_apply: 0, provisioning (progress:0/finished:1), need reboot: 0  
May 24 13:32:00.442 [NOTICE] PHN: TPL: Socket 51 idle/connect timeout
May 24 13:32:02.443 [NOTICE] PHN: TPL: Socket 52 idle/connect timeout
May 24 13:32:03.707 [INFO  ] PHN: WEB: Request 53/693/0: POST /log.htm HTTP/1.1
May 24 13:32:03.712 [DEBUG0] CFG: apply_value: callrecord_dialed_local = '"SIPTELEFONNUMMER" <ACCOUNTNAMESIPTELEFON@sip.alice-voip.de>', need_apply: 0, provisioning (progress:0/finished:1), need reboot: 0  
May 24 13:32:03.713 [DEBUG0] CFG: apply_value: callrecord_dialed_remote = '<sip:AUSGEHENDETELEFONNUMMER@sip.alice-voip.de;user=phone>', need_apply: 0, provisioning (progress:0/finished:1), need reboot: 0  
May 24 13:32:03.717 [DEBUG0] CFG: apply_value: callrecord_dialed_period = '2025-05-24T11:30:49ZPT0S', need_apply: 0, provisioning (progress:0/finished:1), need reboot: 0  
May 24 13:32:03.718 [DEBUG0] PHN: ContactUtils::GetVcard: identity=1
May 24 13:32:03.727 [INFO  ] TOOLS: Going to write file ./snomconfig/config.xml. 
May 24 13:32:03.772 [NOTICE] PHN: Std-Settings stored
"  

Hier der SIP Trace:

;tag=jzuoxx3w4q
To: <sip:AUSGEHENDETELEFONNUMMER@sip.alice-voip.de;user=phone>
Call-ID: e3ad3168c4ec-cpympxsg9oo8
CSeq: 1 CANCEL
Max-Forwards: 70
User-Agent: snomD713/10.1.119.12
Reason: SIP;cause=487;text="Request terminated by user"  
Authorization: Digest username="ACCOUNTNAMESIPTELEFON",realm="ims.telefonica.de",nonce="723d4eea11b313af344250133d111626",uri="sip:epc.mnc007.mcc262.3gppnetwork.org",qop=auth,nc=00000003,cnonce="6fa4df5c",response="e9544eb8801e38817df0dbe78e172c03",algorithm=MD5  
Content-Length: 0



Sent to Udp:EXTERNE-IP:5060 from Udp:192.168.100.152:44675 at May 24 13:31:27.867 (703 bytes):

CANCEL sip:ACCOUNTNAMESIPTELEFON@sip.alice-voip.de;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.100.152:44675;branch=z9hG4bK-a97gkhqg79v0;rport
From: "SIPTELEFONNUMMER" <sip:ACCOUNTNAMESIPTELEFON@sip.alice-voip.de>;tag=jzuoxx3w4q  
To: <sip:AUSGEHENDETELEFONNUMMER@sip.alice-voip.de;user=phone>
Call-ID: e3ad3168c4ec-cpympxsg9oo8
CSeq: 1 CANCEL
Max-Forwards: 70
User-Agent: snomD713/10.1.119.12
Reason: SIP;cause=487;text="Request terminated by user"  
Authorization: Digest username="ACCOUNTNAMESIPTELEFON",realm="ims.telefonica.de",nonce="723d4eea11b313af344250133d111626",uri="sip:epc.mnc007.mcc262.3gppnetwork.org",qop=auth,nc=00000003,cnonce="6fa4df5c",response="e9544eb8801e38817df0dbe78e172c03",algorithm=MD5  
Content-Length: 0

.. und was auch für die Telefonie bei o2-DSL extrem wichtig ist: Es muss zwingend der dem Anschluss zugeordnete (o2) DNS-Server verwendet werden, das ist ähnlich bei einem Telekom Anschluss.

Hier gibt's auch noch weitere Konfigurationstipps für o2 VoIP über einen Fremdrouter: O2 VoIP mit Fritzbox als Client hinter OPNsense (musst Du halt nur auf Deinen Cisco übertragen).

SIP Destination Error und Transport Error sprechen ja schon für sich das die SIP Daten falsch sind!!
Wie vermutet kommt gar keine gültige SIP Session vom Telefon zum SIP Server zustande. Der Router und seine Konfig hat mit dem Problem primär also nix zu tun!
Es sei denn du propagierst intern an die SIP Clients per DHCP einen anderen DNS als den O2 DNS wie Kollege @cykes schon gesagt hat?

So sollte es aussehen:

SIP Statuscode 200 (Notify OK) bei der Registrierung (Subscribe) am SIP Server
Resultiert dann in einer tcp registered Message am Phoner Client
Rausgehender SIP Call fehlerlos mit einem invite

Works as designed!

ok also registriert ist der sip client und das telefon . also den DNS prüfen? dort eintragen bei Zeile 332 von meinem config post?
Ist es die externe Ip Adresse nach Sent to Udp: und vor 5060 aus dem SIP Trace welchen ich gepostet habe? Ich werde erst einmal wie einträge SIP match protocol und RSTP herausnehmen und probieren was passiert.
Danke vorab!

so also ich habe die match einträge von sip bi rstp herausgenommen und den blocktext leicheneintrag entfertn und ich kann ausgehend telefonieren! wow. aber eingehend geht es weiterhin nicht. hilft das weiter? ich gehe davon aus dass hat nichts mit den dns zutun weil ausgehend ja funktioniert oder etwa nicht?

dort eintragen bei Zeile 332 von meinem config post?

Nein, das ist das Kommando was den Cisco selber zu einem Caching DNS Server macht.
Relevant für den zu lernenden Provider DNS ist Zeile 323.
Ob der Router den richtigen Provider DNS Server gelernt hat kannst du mit dem Kommando show hosts selber überprüfen statt zu raten.

aber eingehend geht es weiterhin nicht.

Versuche mal einen ausgehenden Anruf und nach dem Auflegen dich direkt innerhalb von 30 Sekunden zurückzurufen. Klappt das?
Wenn ja kann es sein das du am UDP Timeout scheiterst. Grund ist meistens ein falsch konfiguriertes SIP Keepalive oder ein fehlender STUN Server. Oftmals passiert das wenn man statt TCP fälschlicherweise UDP bei SIP verwendet.
Achte am Softphone darauf das du dort TCP anhakst!

Ich gehe davon aus dass hat nichts mit den dns zutun weil ausgehend ja funktioniert

Das ist korrekt!

P.S.: Bitte die Forenregeln beachten! Insbesondere korrekte Rechtschreibung (Groß- Klein). Das hilft allen hier!

Gibt es denn eine Möglichkeit die Zone based firewall mit match protocol weiter zu betreiben so dass die Protokolle sip , sip-tls und rtsp?

Also wenn ich erst ausgehend telefoniere und mich anrufe funktioniert es aber das war beim SNOM aber mir ist unklar wo ich den Haken beim SNOM setzen soll? Ich habe das mit dem ausgehend anschließend eingehend anrufen getestet und dieses hat funktioniert aber wenn ich unter SNOMD713 -> SETUP -> Configuration Identity 1 -> MEDIA TRANSPORT OFFER -> TCP Einträge hat diese keine Auswirkung. In dem selben Menü gibt es folgende Einträge: NAT Identity Settings
STUN Server (IP-Address:Port)
STUN Interval (s)
Keepalive Interval (s)
Number of Initial Keep-Alives on RTP Port
Determine Public Address from REGISTER Response Via Header
Wo oder welcher Eintrag könnte der richtige Eintrag sein?

Als ich MEDIA TRANSPORT OFFER auf TCP gestellt habe konnte ich noch bei Media Transport Offer Setup ( vorher war es nicht da) etwas auswählen nämlich active, passive oder any kann man mir sagen ob mir dieses vllt hilft?

Oder wie kann ich SIP Keepalive oder ein fehlender STUN Server bei mir einrichten oder abändern?

Unter settings gab es noch etwas das heist user_media_transport_offer1=udp
user_media_transport_offer2=udp
user_media_transport_offer3=udp
user_media_transport_offer4=udp
user_media_transport_offer5=udp
user_media_transport_offer6=udp

Ich kann dieses auf tcp ändern aber es ändert sich nichts.

Kann mir bei der Gelegenheit jemand sagen wie ich die ^C Zeichen am Anfang und Ende meines banner motd wegbekomme?

Aber schon einmal vielen Dank.

Gibt es denn eine Möglichkeit die Zone based firewall mit match protocol weiter zu betreiben so dass die Protokolle sip , sip-tls und rtsp?

Ja natürlich! Das ist sehr einfach.
Du lässt dafür einfach die 3 "match protocol..." für sip, sip-tls und für rtsp schlicht und einfach weg.
Damit rennt die SIP und RTSP Protokoll Inspection über die globale UDP und TCP Inspection am Ende.
Sie werden dann nicht bis in die Tiefe untersucht sondern nur über den TCP oder UDP Header.
Wie oben schon mehrfach gesagt fixt das dann in der Regel auf die Fehlermeldung und die Fehlfunktion.

So wie es aussieht hast du oben keine Fehlfunktion des Routers oder der Firewall sondern eine Fehlkonfiguration beim SIP auf den Endgeräten. Bei UDP Encapsulation öffnet die Firewall für max. 150 Sekunden (plus/minus je nach Hersteller) den Port. Jeder Traffic retriggert den 150 Sek. Timer. Deshalb kann man sich innerhalb dieser Zeit auch problemlos anrufen.
Passiert aber nix dann schliesst die Firewall den Port wieder und eingehende UDP SIP Sessions (bei Anrufen) scheitern verständlicherweise.
Das passiert wenn keine SIP Keepalives gesendet werden oder eben UDP verwendet wird für SIP. Bei TCP passiert das durch den Sessionerhalt nicht. Die Firewall kann am TCP Sessionheader erkennen das die Session aktiv gehalten wird und hält den SIP Port offen.
Dies Verhalten ist immer so an Firewalls bei SIP. Siehe dazu auch HIER.

etwas auswählen nämlich active

Geraten wäre das wohl "active". Active Keepalives. Wie gesagt geraten und sagt dir, wie immer, das Handbuch des Gerätes.

In dem selben Menü gibt es folgende Einträge:

Das wichtigste ist dort das Keepalive Setting.
Was passiert mit dem Phoner Softphone wenn du SIP dort auf TCP setzt? Ist das zu jeder Zeit anrufbar?

Ich hatte mich verschrieben ich wollte wissen ob es eine Möglichkeit gibt das match protocol sip usw drin zu lassen. Dass es raus muss habe ich ja umgesetzt das ausgehend funktioniert.

Also die anderen Einstellungen sind doch bei NAT Identity Settings STUN Server (IP-Address:Port)
STUN Interval (s),Keepalive Interval (s),Number of Initial Keep-Alives on RTP Port,Determine Public Address from REGISTER Response Via Header und nicht bei RTP
Hier die Bilder von den Einstellungen vllt könnt Ihr mir dann helfen auf deutsch und englisch

die Zone based firewall mit match protocol weiter zu betreiben

Ja klar das klappt.
Hier rennen Auerswald Anlage, FritzBox im Client Mode, Cisco Telefone, Gigaset VoIP-Dect Knoten, Panasonic VoIP-Dect Telefon, Phoner Softphone usw. völlig problemlos mit den 3 relevanten match protocol ... Kommandos.
Die Auerswald sogar im UDP Mode mit 180 Sek Keepalive und ohne Error Messages. Das ist bei dir in jedem Falle falsch das bei UDP auf 0 zu lassen. Setze den Keepalive in jedem Fall!

Was du in jedem Falle nochmal probieren solltest ist die von Cisco recommendete Firmware für den 926er zu benutzen. Das ist aktuell die Version 15.9.3M0a(ED).
Es ist gut möglich das deine MD Edition einen Fehler im ZFW Protokollhandling hat. Das passiert manchmal auch innerhalb des gleichen Releasetrains.
Einfach das als 2tes Image ins Flash laden und das system boot ... Kommando anpassen.

Vielen Dank. aber das ist doch eine alte Firmeware oder?
Auf dem SnomD713 habe ich die Werte unter Identität 1 -> NAT -> Anzahl der initialen Keep-Alives über RTP-Port -> auf 180 gestellt und einmal mit Identität 1 -> RTP -> Medientransport via TCP und auch einmal ohne probiert und es ändert sich leider nichts.
Was kann es noch sein ich möchte doch so gerne auch angerufen werden können. Auf dem Cisco Router tut sich gar nichts also es wird nicht von der Firewall geblockt.

Gruß Mario

aber das ist doch eine alte Firmeware oder?

Nope! Es ist das offiziell für den 900er recommendete Image von Cisco!
software.cisco.com/download/home/286315020/type/280805680/releas ...
Man achte auf das Sternchen!

Poste bitte nochmal den Karteireiter "SIP" des Telefons. Das hast du oben leider vergessen. Dort stehen sehr wahrscheinlich alle relevanten Einstellungen der Signalisierung und da ist nochwas falsch.
Nochmals die Frage: Was passiert mit dem Phoner Softphone wenn du SIP dort auf TCP setzt? Ist der Phoner zu mindestens zu jeder Zeit anrufbar?

@aqui: Ja das Softphone funktioniert mittlerweile danke.

Ich hoffe du meinst das mit Karteireiter?

Wenn das DER hier ist...

dann ja. Ansonsten ist der Eingekringelte gemeint!

Als Beispiel hast du mal eine Session Ausgabe der ZFW mit einem Phoner Softphone (SIP mit TCP, Port 5060) was auf einen Sipgate Account gemappt ist und 24/7 anrufbar ist.
Die ZFW hat alle 3 Voice relevanten match protocol .. Settings aktiv!
Wenn der Phoner Client (192.168.1.183) SIP registriert ist OHNE aktiven Call:

Cisco#sh policy-map type inspect zone-pair sessions source 192.168.1.183 | include sip
      Match: protocol sip
      Match: protocol sip-tls
      Match: protocol sip
      Match: protocol sip-tls
         Session ID 0x0001E179 (192.168.1.183:50195)=>(212.9.44.244:5060) sip SIS_OPEN
         Session ID 0x0001E04D (192.168.1.183:50028)=>(212.9.44.242:5060) sip SIS_CLOSED
         Session ID 0x0001E050 (192.168.1.183:0)=>(212.9.44.242:5060) sip SIS_PREGEN
         Session ID 0x0001E17C (192.168.1.183:0)=>(212.9.44.244:5060) sip SIS_PREGEN 

Dto. mit aktivem Anruf

Cisco#sh policy-map type inspect zone-pair sessions source 192.168.1.183 | include sip
      Match: protocol sip
      Match: protocol sip-tls
      Match: protocol sip
      Match: protocol sip-tls
         Session ID 0x0001E224 (192.168.1.183:5062)=>(212.9.44.185:17132) sip-RTP-data SIS_OPEN
         Session ID 0x0001E22D (192.168.1.183:5060)=>(217.10.77.244:5060) sip SIS_OPEN
         Session ID 0x0001E225 (192.168.1.183:5063)=>(212.9.44.185:17133) sip-RTP-data SIS_OPEN
         Session ID 0x0001E179 (192.168.1.183:50195)=>(212.9.44.244:5060) sip SIS_OPEN
         Session ID 0x0001E04D (192.168.1.183:50028)=>(212.9.44.242:5060) sip SIS_CLOSED
         Session ID 0x0001E050 (192.168.1.183:0)=>(212.9.44.242:5060) sip SIS_PREGEN
         Session ID 0x0001E17C (192.168.1.183:0)=>(212.9.44.244:5060) sip SIS_PREGEN 

Das sollte bei dir identisch aussehen! 🤔

Hi Mario,

ich würde auch erstmal Dinge wie RTP Verschlüsselung ausschalten und da keine lokale TK-Anlage vorhanden ist auch TLS-Verschlüsselung (Secure) SIP aauf aus stellen. Das müssen beide (Gesprächs-)Parteien unterstützen und da es um eingehende Anrufe geht, kannst Du Dir da nicht sicher sein. Versuche ersteinmal alles mit möglichst wenig Features, wenn das dann funktioniert, kannst Du ja weiter experimentieren.

Gruß

cykes

@aqui Ok ich werde das Bild vom SIP Kartenreiter auch noch hochladen aber morgen :D

@cykes Ich gehe davon aus am Telefon. Sonst kann ich das ja nicht einstellen. Vielen Dank

@cykes Ich gehe davon aus am Telefon. Sonst kann ich das ja nicht einstellen. Vielen Dank

Ja, genau, da ja keine TK-Anlage vorhanden ist -> in Deinem letzten Screenshot bspw. unter RTP-Verschlüsselung (und weitere) zu sehen.

Ja das Softphone funktioniert mittlerweile danke.

Bestätigt ja dann das der böse Buhmann ausschliesslich dein Snom ist bzw. dessen Konfig!

Hier die Bilder den Einstellungsvorschlag von cykes habe ich ausprobiert und es hat nichts genützt leider. für aqui das Bild des SIP Karteireiters

habe ich ausprobiert und es hat nichts genützt leider.

Da wirst du dann nicht umhinkommen einmal den Wireshark anzuschmeissen. Capture Filter auf UDP und TCP Port 5060 ("port 5060") und checken was da genau abgeht bei der Registrierung des Snom Telefons. Irgendwas muss da schieflaufen, denn wenn es mit den Phoner Softphone fehlerlos rennt kann es nur das Snom sein.

Alternativ könntest du, sofern du noch irgendwo ne olle Fritte in der Bastelschublade rumliegen hast, diese als IP Client konfigurieren, ins lokale Netz als lokale VoIP Anlage hängen und dann mal mit dem Snom versuchen lokal und ohne FW dazwischen eine SIP Verbindung direkt auf die Fritzbox zu realisieren.
Scheitert das auch, dann hast du den ultimativen Beleg das irgendwas am Snom schiefläuft bzw. grundsätzlich falsch konfiguriert ist.

Intensive Tests mit dem aktuellen M11 Patch und der Cisco recommendeten M0a auf der 900er Plattform mit einem Phoner Softphone VoIP Client über SIPgate bestätigten deinen Fehler!
Fazit:
In beiden Versionen ist das SIP spezifische Checking in der ZFW Firewall buggy!

Es erscheint schon bei der eigentlichen SIP Registrierung ein "%AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Mandatory header field missing) - resetting tcp session" Error im Log was dann das Passieren der SIP Session verhindert und damit den VoIP Betrieb unmöglich macht.
Auch ein Ändern der SIP Encapsulation auf UDP brachte keine Lösung. Zwar verschwindet dann die o.a. ZFW Fehlermeldung im Log es kann aber dennoch keine SIP Verbindung aufgebaut werden. Das mag aber auch daran liegen das SIPgate ggf. kein auf UDP basierendes SIP akzeptiert. Müsste man nochmal checken?!
Mit TCP ist der Fehler in jedem Falle reproduzierbar.

Daraus bleibt dann der Schluss das dein SNOM Knochen sehr wahrscheinlich NICHT der böse Buhmann ist sondern das 900er Image auf dem Cisco 900.
Interessanterweise funktionierte ein völlig identisches ZFW Setup mit einem Cisco 886va, 896 und 1100er jeweils in der recommendeten Version als auch in der latest und greatest absolut fehlerfrei MIT aktiver SIP Inspection in der ZFW. Es ist also de facto ein Cisco 900 spezifisches Problem der ZFW.
Wenn dein 900er unter Wartung ist solltest du in jedem Falle einen TAC Case bei Cisco diesbezüglich aufmachen! Da die anderen Router allesamt nicht betroffen sind ist das sicher schnell zu fixen.

Es gibt einen sehr einfachen Workaround bis zu einem Fix:
Entferne einfach mit no match protocol sip nur die SIP spezifische Protocol Inspection!
Die TLS und auch die RTSP Inspection kannst du belassen da die nachweislich nicht betroffen sind.
Damit läuft SIP über die normale TCP Inspection und die VoIP Telefonie funktioniert fehlerlos mit beiden o.a. Firmware Images auf dem 900er.

Ok danke. Ich muss erst einmal dabei belassen vielen dank für eure Mühe. Ich habe mit Yealink gute Erfahrungen gemacht und möchte Wissen ob dieses oder in Bezug auf andere VoIP Telefon dieses jemand teilt?

Ich muss erst einmal dabei belassen vielen dank für eure Mühe.

Was denn belassen?? Den o.a. Workaround? 🤔
Interessant vielleicht noch das ein Cisco 7970 Telefon mit der SIP Inspection zwar ausgehend am 900er funktionierte aber kein Call reinkam. Bei eingehenden SIP Calls kam beim 900er sofort wieder die o.a. ZFW Error Meldung bzgl. des Header Field Fehlers. Korreliert also zu deiner Beobachtung.
Bei allen anderen Cisco Routern unterblieb das und das Telefon funktionierte problemlos. Auch das zeigt de facto ein 900er spezifisches Problem.

Wie gesagt: Mit dem Entfernen der spezifischen SIP Inspection in der ZFW Firewall beim 900er funktionieren alle getesteten Telefone völlig fehlerlos. Auch ein altes SNOM 360.
Damit hat man einen sehr einfachen Workaround ohne auf die Sicherheit der ZFW verzichten zu müssen und bekommt VoIP problemlos zum Laufen.
Bei Yealink hört natürlich der Chinese immer mit. Ob du das willst oder nicht musst du selber entscheiden.

Nochwas zum Thema Uhrzeit... Dieser Punkt deiner Frage ist hier leider etwas untergegangen im Eifer des VoIP Gefechts.
Der Grund keiner oder der falschen Uhrzeit liegt leider auch wieder in einer NTP Fehlkonfiguration des Routers deinerseits!

Die Zeitzone usw. stimmt, aber es fehlt vollständig die Angabe eines NTP Servers von dem der Router seine Uhrzeit zieht. Z.B.

ntp source Dialer 0
ntp update-calendar
ntp server de.pool.ntp.org 

Mit sh ntp stat oder auch sh ntp ass kannst du dir den NTP Status ansehen und mit sh clo auch das korrekte Uhrzeit Setting.
👉🏽 Wichtig zu wissen ist das der Cisco damit als NTP Proxy arbeitet im lokalen Netzwerk. Du kannst die Cisco Router IP Adresse dann bei allen lokalen Endgeräten als NTP Zeitserver angeben und sie zusätzlich auch per DHCP in der DHCP Konfig mit option 42 ip <router_ip_addr> allen Endgeräten mitgeben.

(Siehe Tutorial)

Nabend,

ich glaube, Mario möchte erstmal die weitere Bearbeitung unterbrechen (oder sogar abbrechen)!? Im Endeffekt wirst Du - wie @aqui das bei seinen Tests dargelegt hat - mit jedem SIP-Telefon diese oder ähnliche Probleme i.V.m. dem 900er Cisco haben. Grundlegend arbeiten die alle gleich. Das Yealink ist da keine Ausnahme, also jetzt nicht wegen dieses Bugs ne Materialschlacht starten.
So steht es auch in den Threadsim Cisco Forum, die ich eingangs verlinkt habe, Darfste Dir gern mal durchlesen ...

Gruß

cykes