Warum O2
Warenkorb
 Service
Gelöst

Snom D385 IP-Telefon hinter Router am O2-DSL-Anschluss

D
Rang

Hallo miteinander,

 

ich habe einen O2-DSL-Anschluss und betreibe den mit Ipfire als Router (keine Fritzbox). Jetzt wollte ich die im Paket enthaltenen SIP-Telefonie auch mit einem Snom D385 nutzen. Leider funktioniert es noch nicht (vollständig). Ich kann ohne Probleme raus telefonieren. Wenn ich aber von aussen rein rufe, dann klingelt mein Snom, wenn ich abnehme, zeigt das Snom verbunden an, am externen Telefon bekomme ich aber weiter ein Freizeichen und kann natürlich nichts hören. Wenn ich extern dann auflege, bekommt das das Snom mit.

 

  • Das Telefon hat die O2-DNS-Server eingetragen.
  • Die Konfiguration vom Snom habe ich mit den Angaben hier 

     vorgenommen.

  • Ein auf dem gleichen Telefon eingerichteter Sipgate-Account funktioniert.

  • Ich habe versucht den Sipgate-Account zu deaktivieren, bringt nichts.

  • Ich habe versucht einen Stun-Server (stun.l.google.com) einzutragen, bringt nix.

  • Ich habe versucht die UDP-Ports von extern ans Snom weiterzuleiten (Portforwarding von 5160, 5104-5120, 3478, das sind die Ports, mit denen Sipgate auch funktioniert) 

  • Ich habe Portweiterleitung und Stun gleichzeitig probiert, bringt auch nix.

Ich hab jetzt auch nach längerer versuchter Recherche nix mehr gefunden, was ich noch probieren kann, bin aber, was SIP angeht auch noch ein recht blutiger Anfänger.

 

Hat da evtl, jemand einen Tip für mich? (Fritzbox ist keine Alternative, ich brauche verschiedene Features des Ipfire-Setups)

Danke schonmal und viele Grüße

 

Daniel

icon

Lösung von duesed4 30 March 2024, 21:51

Zur Antwort springen

18 Antworten

D
Rang

War die falsche Kategorie, sorry.

 

Edit o2_Sven 26.03.2024/08:17: Beiträge zusammengeführt

bielo
Rang

 

o2_Sven

Hallo @duesed4 ,

herzlich willkommen bei uns in der o2 Community 💙.

Wir löschen generell keine Beiträge hier, wenn es dir in der Zukunft noch einmal passieren sollte dass du ein Thema im falschen Bereich eröffnest oder sonst etwas nicht stimmt, dann kannst du uns gerne über die Meldenfunktion darüber aufmerksam machen und wir verschieben das Thema dann in die korrekte Sparte.

 

Schöne Grüße, Sven

Der Wochenrückblick - https://g.o2.de/wcr
D
Rang

Dankeschön 😊

👍

Viele Grüße Daniel

Klaus_VoIP
Rang

In den meisten Fällen liegt es dann an unzureichenden Einstellungen der Firewall - hier Ipfire.

Außerdem sollte man nicht von Sipgate ausgehen, denn o2 verwendet andere Portbereiche, zumindest für RTP. Zuerst würde ich mal nach einer ALG-Funktion für SIP in Ipfire oder dem vorgeschalteten Modem-Router(?) schauen. Hier scheint eingehend nichts am Snom anzukommen, was an einer zu strikten Firewall liegen könnte.

Meine persönlichen Meinungsäußerungen als Kunde sind NICHT gesponsert und stellen nur meine unverblümte Meinung dar! Dafür erfolgen alle Inhalte pro bono publico. ;-)
D
Rang

Hallo Klaus,

vielen Dank für die Antwort.

ALG gibt es in ipfire nicht (mehr). Das kann ich also nicht aktivieren

 

Ich habe jetzt die Ports mal angepasst:

SIP: 5060

RTP: 7078-7110

(hier im Forum gefunden).

Hat leider nix gebracht. Die Portweiterleitung UDP 5060,7078-7110 → Snom habe ich auch angepasst. Ich hab auch probiert ALLE UDP Ports von außen ans Snom weiterzuleiten, das hat leider auch nix gebracht. Selbiges mit TCP. Dann war zwar das Webinterface vom Snom von außen erreichbar, hat aber trotzdem nix gebracht. Ich habe auch in der Firewall keine passenden DROP Einträge im Log gefunden.

Klaus_VoIP
Rang

welches Modem hängt vor der FW?

Meine persönlichen Meinungsäußerungen als Kunde sind NICHT gesponsert und stellen nur meine unverblümte Meinung dar! Dafür erfolgen alle Inhalte pro bono publico. ;-)
D
Rang

Müsste ein ZyXEL VMG1312-B50A sein (nicht 100% sicher, muss nochmal im Keller schauen).

Das läuft aber rein als Modem. D. h. PPPoE Einwahl und NAT macht alles Ipfire. Das Zyxel sollte also keinen Einfluss auf SIP haben?

D
Rang

Update: Ja, ist ein ZyXEL VMG1312-B50A.

P
Rang

Wie sind denn die conntrack timeouts eingestellt (fuer TCP und UDP)?

sysctl -a | grep -e net.netfilter.nf_conntrack_

Und nutzt das SNOM UDP oder TCP (oder beides), sollte sich per packet capture schnell verifizieren lassen.

D
Rang

Danke schonmal für die Antwort.

 

Bei einem bestehenden (ausgehenden, funkionierenden) Gespräch sehe ich in der Firewall nur UDP-Verbindungen zum Snom. Auch in den SIP/RTP Einstellungen finde ich nur Einstellungen, die auf UDP stehen.

Unten die Abfrage zum Timeout.

UDP steht auf 30 bzw 120 (stream). Auf was sollte das denn stehen?

[root@ipfire ~]# sysctl -a | grep -e net.netfilter.nf_conntrack_
net.netfilter.nf_conntrack_acct = 1
net.netfilter.nf_conntrack_buckets = 65536
net.netfilter.nf_conntrack_checksum = 1
net.netfilter.nf_conntrack_count = 648
net.netfilter.nf_conntrack_dccp_loose = 1
net.netfilter.nf_conntrack_dccp_timeout_closereq = 64
net.netfilter.nf_conntrack_dccp_timeout_closing = 64
net.netfilter.nf_conntrack_dccp_timeout_open = 43200
net.netfilter.nf_conntrack_dccp_timeout_partopen = 480
net.netfilter.nf_conntrack_dccp_timeout_request = 240
net.netfilter.nf_conntrack_dccp_timeout_respond = 480
net.netfilter.nf_conntrack_dccp_timeout_timewait = 240
net.netfilter.nf_conntrack_events = 2
net.netfilter.nf_conntrack_expect_max = 1024
net.netfilter.nf_conntrack_frag6_high_thresh = 4194304
net.netfilter.nf_conntrack_frag6_low_thresh = 3145728
net.netfilter.nf_conntrack_frag6_timeout = 60
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_icmpv6_timeout = 30
net.netfilter.nf_conntrack_log_invalid = 0
net.netfilter.nf_conntrack_max = 65536
net.netfilter.nf_conntrack_sctp_timeout_closed = 10
net.netfilter.nf_conntrack_sctp_timeout_cookie_echoed = 3
net.netfilter.nf_conntrack_sctp_timeout_cookie_wait = 3
net.netfilter.nf_conntrack_sctp_timeout_established = 210
net.netfilter.nf_conntrack_sctp_timeout_heartbeat_sent = 30
net.netfilter.nf_conntrack_sctp_timeout_shutdown_ack_sent = 3
net.netfilter.nf_conntrack_sctp_timeout_shutdown_recd = 3
net.netfilter.nf_conntrack_sctp_timeout_shutdown_sent = 3
net.netfilter.nf_conntrack_tcp_be_liberal = 0
net.netfilter.nf_conntrack_tcp_ignore_invalid_rst = 0
net.netfilter.nf_conntrack_tcp_loose = 1
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_timestamp = 0
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 120

 

P
Rang
 
net.netfilter.nf_conntrack_udp_timeout = 60
net.netfilter.nf_conntrack_udp_timeout_stream = 180

Unter OpenWrt mit Kernel 5.15 sehe ich in tcpdump:

root@turris:/srv/persistent$ tcpdump -i br-lan -vv 'src 192.168.42.61' or 'dst 192.168.42.61'
tcpdump: listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
09:52:04.206682 IP (tos 0x88, ttl 128, id 11992, offset 0, flags [none], proto UDP (17), length 32)
    192.168.42.61.5060 > 62.53.238.131.5060: [udp sum ok] SIP
09:52:24.216510 IP (tos 0x88, ttl 128, id 11993, offset 0, flags [none], proto UDP (17), length 32)
    192.168.42.61.5060 > 62.53.238.131.5060: [udp sum ok] SIP
09:52:44.228064 IP (tos 0x88, ttl 128, id 11994, offset 0, flags [none], proto UDP (17), length 32)
    192.168.42.61.5060 > 62.53.238.131.5060: [udp sum ok] SIP
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel

 D.h. wie in der SIP-Basis konfiguriert alle 20 Sekunden ein Keep-Alive Packet (bei Gigaset heisst die Option ‘NAT refresh’) dass dafuer sorgt, dass der 60 Sekunden UDP Connection timeout nicht zum Zuge kommt.

D
Rang

Das kann ich als  “Keepalive-Intervall (s)” in den NAT-Einstellungen der SIP Identität einstellen. Stand auf 60, jetzt 20, sehe ich auch im tcpdump. Macht aber leider keinen Unterschied. 

D
Rang

Ich hab jetzt auch nochmal probiert die RTP-Ports zu erweitern (auf 6000-20000), den SIP-Port auf 5061 zu setzen und auch mit entsprechenden Portweiterleitungen in der Firewall. Kein Unterschied.

Mein Bauch sagt mir, das hängt wahrscheinlich nicht an der Stelle, weil sich da so gar nix tut (kann sich aber natürlich auch irren, der Bauch).

 

Ich vermute irgendeine Einstellung in der Konfiguration von dem Telefon schmeckt O2 nicht. Ich weiß aber nicht, wie ich da alleine weiter machen soll. Hat jemand ein Snom (welches sollte egal sein, da da überall die selbe Firmware drauf läuft) am O2-Anschluss in Betrieb und wäre mir bereit seine Konfiguration bzw. Screenshots davon (ohne Zugangsdaten natürlich) zur Verfügung zu stellen oder hier zu posten? Danke schonmal...

D
Rang

Ich hab nochmal etwas weiter probiert und in der SIP-Protokollierung vom Snom was gesehen. Das Snom schickt einen Fehler “481 Call Leg/Transaction Does Not Exist” und das unabhängig davon, ob ich Portweiterleitungen aktiv und/oder einen Stun-Server eingetragen hab. 

 

Sent to Udp:62.52.19.67:5060 from Udp:192.168.122.139:5060 at Mar 30 19:32:34.884 (776 bytes):

SIP/2.0 481 Call Leg/Transaction Does Not Exist
Via: SIP/2.0/UDP 62.52.19.67:5060;oc-algo="loss";oc;rport=5060;branch=z9hG4bKmavodi-0-264-7c-7-1000000-7abe0000-608f9b0fd8abe-112e-ffffffffffffffff-106a-4f7d0000-608f9b0fa543a-4211016115-9150
From: "0179XXXXXXX" <sip:0179XXXXXXX@telefonica.de>;tag=mavodi-__v~zsvtvuy~ruz__0-10d-11-8-ffffffff-131e-0-0-0-1711823556-_000000000000-2d53-ff088700-107f48-66085ac4-20537
To: <tel:+498142XXXXXX;tag=duc97u1ny0>
Call-ID: FA163EE97A38-2d53-ff088700-1f242bc-66085ac4-2041a
CSeq: 2 PRACK
User-Agent: snomD385/10.1.84.15
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Content-Length: 0

Kann jemand von Euch damit was anfangen? Ich hab dazu noch nix aussagekräftiges gefunden. Bin aber wie gesagt auch Anfänger auf dem Gebiet.

D
Rang

Update:

 

Hier ist der komplette Rufaufbau bis zum Fehler:

 

	
Received from Udp:62.52.19.67:5060 on Udp:192.168.122.139:5060 at Mar 30 19:32:34.656 (1972 bytes):

INVITE sip:498142XXXXXX@77.2.25.62:5060;line=cca8ctp0 SIP/2.0
Via: SIP/2.0/UDP 62.52.19.67:5060;oc-algo="loss";oc;rport;branch=z9hG4bKmavodi-0-264-7c-7-1000000-7abe0000-608f9b0fd8abe-112e-ffffffffffffffff-106a-4f7d0000-608f9b0fa543a-4210803848-9150
Max-Forwards: 68
From: "0179XXXXXXX" <sip:01795205780@telefonica.de>;tag=mavodi-__v~zsvtvuy~ruz__0-10d-11-8-ffffffff-131e-0-0-0-1711823556-_000000000000-2d53-ff088700-107f48-66085ac4-20537
To: <sip:+4981424XXXXXX@sip.alice-voip.de;user=phone>
Call-ID: FA163EE97A38-2d53-ff088700-1f242bc-66085ac4-2041a
CSeq: 1 INVITE
Min-SE: 90
Session-Expires: 1800
Contact: <sip:mavodi-0-266-83b-7-fffffff1-40d80000-608f9b0fd8809-112e-ffffffffffffffff-@62.52.19.67:5060>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";audio
Accept: application/sdp,application/3gpp-ims+xml
Supported: timer,tdialog,replaces,histinfo,100rel
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,PRACK,MESSAGE,REFER,NOTIFY,INFO,OPTIONS
Record-Route: <sip:mavodi-0-266-83b-7-ffffffff-40d80000-608f9b0fd8809-112e-ffffffffffffffff-mavsipodi-0-26c-106a-7-4f7d0000-608f9b0fa543a-112e@62.52.19.67:5060;lr;mavsipodi-0-26c-106a-7-4f7d0000-608f9b0fa543a-112e>
P-Asserted-Identity: "0179XXXXXX" <sip:+49179XXXXXXX@telefonica.de>,<tel:+49179XXXXXXX;cpc=ordinary>
Content-Type: application/sdp
Accept-Contact: *;explicit;require
Content-Length: 602

v=0
o=ccs-0-615-7 06127977998331 354284438 IN IP4 62.53.175.133
s=QC VOIP
c=IN IP4 62.53.175.133
t=0 0
m=audio 55168 RTP/AVP 126 104 9 102 8 0 96 97
a=sendrecv
a=maxptime:240
a=ptime:20
a=rtpmap:126 EVS/16000/1
a=fmtp:126 hf-only=1;br=5.9-24.4;bw=nb-wb;ch-aw-recv=2;max-red=0
a=rtpmap:104 AMR-WB/16000/1
a=fmtp:104 mode-change-capability=2;max-red=0
a=rtpmap:9 G722/8000
a=rtpmap:102 AMR/8000/1
a=fmtp:102 mode-change-capability=2;max-red=0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/16000
a=fmtp:96 0-15
a=rtpmap:97 telephone-event/8000
a=fmtp:97 0-15

Sent to Udp:62.52.19.67:5060 from Udp:192.168.122.139:5060 at Mar 30 19:32:34.676 (889 bytes):

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 62.52.19.67:5060;oc-algo="loss";oc;rport=5060;branch=z9hG4bKmavodi-0-264-7c-7-1000000-7abe0000-608f9b0fd8abe-112e-ffffffffffffffff-106a-4f7d0000-608f9b0fa543a-4210803848-9150
Record-Route: <sip:mavodi-0-266-83b-7-ffffffff-40d80000-608f9b0fd8809-112e-ffffffffffffffff-mavsipodi-0-26c-106a-7-4f7d0000-608f9b0fa543a-112e@62.52.19.67:5060;lr;mavsipodi-0-26c-106a-7-4f7d0000-608f9b0fa543a-112e>
From: "0179XXXXXXX" <sip:0179XXXXXXX@telefonica.de>;tag=mavodi-__v~zsvtvuy~ruz__0-10d-11-8-ffffffff-131e-0-0-0-1711823556-_000000000000-2d53-ff088700-107f48-66085ac4-20537
To: "O2 - Müllegger" <sip:+498142XXXXXX@sip.alice-voip.de;user=phone>;tag=duc97u1ny0
Call-ID: FA163EE97A38-2d53-ff088700-1f242bc-66085ac4-2041a
CSeq: 1 INVITE
User-Agent: snomD385/10.1.84.15
Contact: <sip:4981424XXXXXX@77.2.25.62:5060;line=cca8ctp0>;reg-id=1
Content-Length: 0


Sent to Udp:62.52.19.67:5060 from Udp:192.168.122.139:5060 at Mar 30 19:32:34.699 (1058 bytes):

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 62.52.19.67:5060;oc-algo="loss";oc;rport=5060;branch=z9hG4bKmavodi-0-264-7c-7-1000000-7abe0000-608f9b0fd8abe-112e-ffffffffffffffff-106a-4f7d0000-608f9b0fa543a-4210803848-9150
Record-Route: <sip:mavodi-0-266-83b-7-ffffffff-40d80000-608f9b0fd8809-112e-ffffffffffffffff-mavsipodi-0-26c-106a-7-4f7d0000-608f9b0fa543a-112e@62.52.19.67:5060;lr;mavsipodi-0-26c-106a-7-4f7d0000-608f9b0fa543a-112e>
From: "0179XXXXXXX" <sip:0179XXXXXXX@telefonica.de>;tag=mavodi-__v~zsvtvuy~ruz__0-10d-11-8-ffffffff-131e-0-0-0-1711823556-_000000000000-2d53-ff088700-107f48-66085ac4-20537
To: "O2 - Müllegger" <sip:+498142XXXXXX@sip.alice-voip.de;user=phone>;tag=duc97u1ny0
Call-ID: FA163EE97A38-2d53-ff088700-1f242bc-66085ac4-2041a
CSeq: 1 INVITE
User-Agent: snomD385/10.1.84.15
Contact: <sip:498142XXXXXX@77.2.25.62:5060;line=cca8ctp0>;reg-id=1
Require: 100rel
RSeq: 1
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Content-Length: 0


Received from Udp:62.52.19.67:5060 on Udp:192.168.122.139:5060 at Mar 30 19:32:34.879 (595 bytes):

PRACK sip:498142XXXXXX@77.2.25.62:5060;line=cca8ctp0 SIP/2.0
Via: SIP/2.0/UDP 62.52.19.67:5060;oc-algo="loss";oc;rport;branch=z9hG4bKmavodi-0-264-7c-7-1000000-7abe0000-608f9b0fd8abe-112e-ffffffffffffffff-106a-4f7d0000-608f9b0fa543a-4211016115-9150
Max-Forwards: 68
From: "0179XXXXXX" <sip:0179XXXXXX@telefonica.de>;tag=mavodi-__v~zsvtvuy~ruz__0-10d-11-8-ffffffff-131e-0-0-0-1711823556-_000000000000-2d53-ff088700-107f48-66085ac4-20537
To: tel:+498142XXXXXX;tag=duc97u1ny0
Call-ID: FA163EE97A38-2d53-ff088700-1f242bc-66085ac4-2041a
CSeq: 2 PRACK
RAck: 1 1 INVITE
Content-Length: 0


Sent to Udp:62.52.19.67:5060 from Udp:192.168.122.139:5060 at Mar 30 19:32:34.884 (776 bytes):

SIP/2.0 481 Call Leg/Transaction Does Not Exist
Via: SIP/2.0/UDP 62.52.19.67:5060;oc-algo="loss";oc;rport=5060;branch=z9hG4bKmavodi-0-264-7c-7-1000000-7abe0000-608f9b0fd8abe-112e-ffffffffffffffff-106a-4f7d0000-608f9b0fa543a-4211016115-9150
From: "0179XXXXXX" <sip:01795205780@telefonica.de>;tag=mavodi-__v~zsvtvuy~ruz__0-10d-11-8-ffffffff-131e-0-0-0-1711823556-_000000000000-2d53-ff088700-107f48-66085ac4-20537
To: <tel:+498142XXXXXX;tag=duc97u1ny0>
Call-ID: FA163EE97A38-2d53-ff088700-1f242bc-66085ac4-2041a
CSeq: 2 PRACK
User-Agent: snomD385/10.1.84.15
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Content-Length: 0

 

Da hat mich jemand drauf aufmerksam gemacht, dass der to:-Header von O2 in der PRACK-Nachricht geändert wird.

 

Ich hab jetzt nochmal alle möglichen Optionen durchgeschaut. Es gibt eine die da lautet "Erzwinge PRACK"

 

Description
Defines whether Required:100Rel will be send or not.
This influences whether a early-dialog via PRACK will be established (if the opposite offers this by sending Supported:100Rel) or not.
This could be useful for playing announcements or music/ring-back-tones during the time the call is in Ringing-state.
Even if set to off, the phone will still offer 100Rel in the Supported-Header if it sends the INVITE (is the originator of the call). If B responses with Required: 100Rel it will send the ACK, independent of this setting.
For preventing sending 100Rel as supported (and by that sending PRACK) you have to set additionally send_prack to off.

Valid Values
On -> Required:100Rel and Prack will be send (if offered by opposite)
Off -> Required:100Rel and Prack wont be send (even if offered by opposite)

Default Value
On

Nachdem der geänderte to: Header in der PRACK Botschaft steckt hab ich die Option einfach mal abgeschaltet, auch wenn ich nicht wirklich verstanden hab, was das jetzt bedeutet, aber: Jetzt gehts!

Das ganze geht auch ohne Portweiterleitung und ohne Stun-Server. Hatte also zur Abwechslung mal nix mit der Firewall zu tun. Ob das auch die DSL Zwangstrennung übersteht muss sich zeigen, wir werden sehen.

Vielen Dank für die Unterstützung...

P
Rang

Respekt, das war gut versteckt!

o2_Dennis

Hi @duesed4,

super, dass du hartnäckig geblieben bist. Ich fürchte, ansonsten würden wir noch lange suchen. Danke auch für deine Rückmeldung, wie du das Problem am Ende lösen konntest. 🙂

VG
Dennis

Deine Antwort


Allgemeine Nutzungsbedingungen der O₂ Community
© Telefónica Germany GmbH & Co. OHG Telefónica