VoIP-Telefonie mit O2 hinter Router

[duese]

Hallo miteinander,

gibt's hier Erfahrung mit VoIP-Telefonie, die nicht direkt im Router sitzt?

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 (muss sein, weil die benötigten Server nur von den O2-DNS aufgelöst werden, diese aber nicht von Ipfire akzeptiert werden, weil Protokoll unsicher oder so). Ipfire kennt die DNS nicht, das dürfte aber nix ausmachen?

• 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 hab auch die Standardports von O2 probiert (5060, 7078ff) und einen deutlich erweiterten RTP-Bereich.

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

• Der Timeout von UDP Verbindungen in der Firewall wurde gecheckt (30s) und der keep-alive kürzer gestellt (20s)

• ALG ist nicht aktiv

Ich hab die Frage auch hier https://hilfe.o2online.de/dsl-kabel-gla ... uss-632460 schon gestellt, weiter also oben bin ich aber nicht gekommen.

Was ich noch nicht gemacht hab, ist die Netzwerkpakete wirklich auf Fußpilzniveau auseinander zu nehmen. Wäre mir auch recht, wenn das nicht notwendig wäre. Wobei ich schon fürchte, dass es darauf rauslaufen wird

O2 ist was VoIP nicht direkt auf der Fritzbox angeht wohl etwas zickig, aber es gibt Leute, bei denen es funktioniert. Den offensichtlichsten O2-VoIP-Fehler (DNS) hab ich schon berücksichtigt.

Hat jemand vielleicht einen Tip, wo ich noch suchen kann oder was ich probieren könnte?

Danke Euch schonmal!

[Kevin_B]

Blöde Frage: hast du auch Port 5060 geöffnet? Wenn ja, schalt mal SIP ALG aus, das kann u.U. auch Probleme bereiten

[duese]

Ja, 5060 und 5061 hab ich auch probiert (sowohl im Telefon konfiguriert als auch mit/ohne Portweiterleitung). Macht keinen Unterschied.

ALG ist aus Ipfire wegen irgendwelcher Sicherheitsbedenken rausgeflogen. Kann also gar nicht aktiv sein.

[Kevin_B]

Tut das Telefon, wenn du’s direkt an den O2-Router hängst? Oder macht der IP-Fire direkt die Einwahl? Ansonsten, was sagen die Firewalllogs? Auch gerne per PN.

[duese]

Kein O2 Router, Ipfire macht die Einwahl.

Ich hab in den Firewall logs in der Weboberfläche keine verdächtigen Drops gesehen. Vielleicht muss das nochmal genauer betrachtet werden... Ich hoffe, ich kann morgen Mal Firewalllogs liefern.

[sukram]

Das DNS vom Telefon lässt der Ipfire auch durch, ohne dran zu schrauben? (Scheint ja, sonst würde der sich nicht registrieren)

Das Telefon macht auch nur IPv4? O2 hat afaik so kaputtes Dual-Stack mit öffentlichem IPv6 und privatem IPv4, richtig? Oder gar nur IPv6 und IPv4 über Tunnel?

Die SIP Ports sind auch TCP+UDP freigegeben?

Mal als STun Server sip.alice-voip.de ausprobiert?

Früher™ habe ich lange Zeit einen Asterisk VoIP Server betrieben, da hatte ich genauso kuriose Startprobleme.

[Roehricht]

Hallo,
man soll feste interne IP-Adressen für die Endgeräte benutzen. Und für die diese IP-Adresse dann den passenden Port freigeben. Dem Apparat muss dann eine internen Rufnummer des Routers oder die Rufnummer die man vom Provider bekommen hat zugeordet werden. Der RTP Port muss auch freigeschaltet werden. Über den laufen die Sprachsignale.

Bei der Fritz Box kann man auf "selbständige Portfreigebe" schalten. Dann handelt das Telefon die Ports mit dem Provider aus.
Wie das bei anderen Routern ist weiss ich nicht.

Ich kämpfe mich auch gerade da durch. Ich hab ne Siemens Hipath mit einem S2M Port über ein Gateway am SIP-Trunk von easybell. Das erste Gateay welches ich benutzt habe liess sich nicht bei easybell anmelden. nach 2 Tagen wilder rumfrickelei hab e ich festgestellt das der Kackmöller eine festgebrannte Telekom Firmware drin hatte und somit für fremde Provider nicht nutzbar ist. Das ist ein Mediant 500 von Audio Codes.

Nun habe ich ein Matrix SETU VTEP Gateway, Der Möller ist in allen Parametern frei programmierbar und man kann eine Ländervoreinstellung für Deutschland aufrufen.
Ankommender Rufe fallen auf den Abwurfplatz ab. Der Apparat der als "Zentrale" eingerichtet ist. Die Durchwahl zu den Nebenstellen klappt noch nicht. Abgehende Rufe sind möglich und werden mit der Hauptnummer angezeigt also 04231 1234-0.
Das das mit der Durchwahl nicht funktioniert kann auch an der Anlagenprogrammierung liegen. Mal kucken. Die Anlage hat zuletzt mit den derzeitigen Einstellungen "Amtsseite" an einem NTPM der Telekom gewerkt. Somit sollte es am SIP-Trunk ohne weiteres tun. Tut es aber nicht.

73
Wolfgang

[b0n3]

Könnte am Ipfire liegen wie er das NAT Routing macht.
Ich kenne ipfire nur oberflächlich.
Mit Opnsense und Pfsense bin ich besser.

Für Voip mit Fritzbox alten Auserwald Anlagen muss man das X aktiviern, 5060 Prot regeln meist auf, viel testn.

Moderne Anlagen haben den mist nicht mehr.
zum testen evtl mal FrePBX füher Asterix testen ob damit das Problem weggeht

[b0n3]

Hallo,
man soll feste interne IP-Adressen für die Endgeräte benutzen. Und für die diese IP-Adresse dann den passenden Port freigeben. Dem Apparat muss dann eine internen Rufnummer des Routers oder die Rufnummer die man vom Provider bekommen hat zugeordet werden.

Blödsinn. feste ips für Telefone ist mega dumm, wenn man das braucht macht man die übern DHCP fest und gut is, Regeln für Firewall und so kann man auch daran festmachen.
Wenn man Feste IPs im Netz nicht perfekt dokumentiert, (was niemand macht zu HAuse) wirst du damit irgendwann nur durchdrehen.

Ich lasse neue Telefonanlagen auf DHCP, macht null Probleme. und man kann den Möller an Jedem ANschluss anschließen und der mist läuft wieder.
Geht sogar an einem MobilHOtspot, aber nicht mit alten Telekom oder Vaderphone anschlüssen

[duese]

Vielen Dank für Eure Antworten. Ich hab eben noch in bisschen weiter geschaut und probiert. Aber eins nach dem anderen.

Das DNS vom Telefon lässt der Ipfire auch durch, ohne dran zu schrauben? (Scheint ja, sonst würde der sich nicht registrieren)

Offenbar ja. Würde mich auch wundern, wenn da was wäre. Ich hab von innen nach außen alles offen.
Neben O2-DNS fest im Telefon eintragen, hab ich jetzt auch noch DNS-Forward für "alice-voip.de" auf die O2-Server im Ipfire eingestellt und das Telefon wieder auf DHCP, damit gehts auch, macht aber keinen Unterschied bei meinem Problem.

Das Telefon macht auch nur IPv4? O2 hat afaik so kaputtes Dual-Stack mit öffentlichem IPv6 und privatem IPv4, richtig? Oder gar nur IPv6 und IPv4 über Tunnel?

Ja, IPv6 ist im Telefon deaktiviert. Ich bekomme von O2 nur eine öffentliche IPv4-Adresse. Was die sonst so treiben, kann ich nicht beurteilen, weil ich es nicht sehe.

Die SIP Ports sind auch TCP+UDP freigegeben?

Jein. Hab verschiedene Kombinationen probiert. Eben auch nochmal TCP mit freigegeben. Ich hatte auch kurzfristig alles an TCP und UDP aufs Telefon freigegeben (also exposed host), hat auch nix gebracht.

Mal als STun Server sip.alice-voip.de ausprobiert?

Dann registriert er den Account erst gar nicht. Mit stun3.l.google.com gehts.

Könnte am Ipfire liegen wie er das NAT Routing macht.
Ich kenne ipfire nur oberflächlich.
Mit Opnsense und Pfsense bin ich besser.

viop.PNG

So ne Option hab ich nicht gefunden. Hab auch noch nie gehört, dass Ipfire automatisch Regeln anlegt. Händisch hab ich das auch versucht, glaube aber inzwischen nimmer, dass es daran liegt, siehe unten.

zum testen evtl mal FrePBX füher Asterix testen ob damit das Problem weggeht

Daran hab ich auch schon gedacht, damit kenn ich mich aber noch weniger als mit IP-Telefonen aus (und das ist schon wenig). Gibts da irgendwas, dass man einfach aufsetzt und ggfs. über eine Oberfläche konfigurieren kann und halbwegs sieht, was passiert? Wenn man sich mit einem System auskennt sind Konfigurationsdateien und Konsole schön. Mach ich an anderer Stelle auch gerne, aber mit SIP bin ich blutiger Anfänger.

Vielleicht trocknet das Blut auch schon etwas, ich hab mich eben mal noch mit der SIP-Protokollierung auf der Telefonoberfläche beschäftigt und was gesehen. Mein Telefon schickt bei Anrufen von außen noch bevor ich abhebe einen Fehler 481:

Code: Alles auswählen

	
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

Diesen schickt es auch unabhängig davon, ob ich Portweiterleitungen aktiv hab oder nicht oder ob ich einen Stun-Server eingetragen hab oder nicht.
Von daher glaube ich nicht mehr, dass es an der Firewall oder so hängt. (Und Sipgate schafft es auch ohne jegliche Portweiterleitung oder STUN-Server Gespräche in beide Richtungen aufzubauen).

Zu dem 481, bzw. der Ursache hier, habe ich bis jetzt noch nix passendes gefunden. Sagt das jemand von Euch was?




Der vollständige Rufaufbau bis zu obigem Fehler:

Code: Alles auswählen

	
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

[b0n3]

So ne Option hab ich nicht gefunden. Hab auch noch nie gehört, dass Ipfire automatisch Regeln anlegt. Händisch hab ich das auch versucht, glaube aber inzwischen nimmer, dass es daran liegt, siehe unten.

zum testen evtl mal FrePBX füher Asterix testen ob damit das Problem weggeht

Daran hab ich auch schon gedacht, damit kenn ich mich aber noch weniger als mit IP-Telefonen aus (und das ist schon wenig). Gibts da irgendwas, dass man einfach aufsetzt und ggfs. über eine Oberfläche konfigurieren kann und halbwegs sieht, was passiert? Wenn man sich mit einem System auskennt sind Konfigurationsdateien und Konsole schön. Mach ich an anderer Stelle auch gerne, aber mit SIP bin ich blutiger Anfänger.

Ich hätte ne vm für Agfeo Hypervoice zum testen, ohne lizenez kann die 2 Geräte, 2 Benutzer.
BEdienung geht ungefähr so: https://info.agfeo.de/agfeo_web/dokulib ... k_0207.pdf

Die VM läuft unter Hyperv oder ESXI
wenn du Windows Pro hast kannst du das auch dort installieren
https://www.heise.de/tipps-tricks/Hyper ... 74931.html
Da kannst du dann dein Telefon ranhängen, wie bei FreePBX auch

worauf läuften der IPfire und warum? würde dir opnsense nahelegen, da sieht man auch mehr.
https://opnsense.org/
kannst du auch live von CD aus laufen lassen zum testen nicht doof

[duese]

Ich hätte ne vm für Agfeo Hypervoice zum testen, ohne lizenez kann die 2 Geräte, 2 Benutzer.
BEdienung geht ungefähr so: https://info.agfeo.de/agfeo_web/dokulib ... k_0207.pdf

Die VM läuft unter Hyperv oder ESXI
wenn du Windows Pro hast kannst du das auch dort installieren
https://www.heise.de/tipps-tricks/Hyper ... 74931.html
Da kannst du dann dein Telefon ranhängen, wie bei FreePBX auch

Öhm, ich hab keinen privaten Rechner mit Windows. Von Hyperv oder ESXI hör ich gerade zu ersten mal.
Wäre das zum testen des Telefons oder auch in Kombination mit dem SIP-Registrar?

worauf läuften der IPfire und warum? würde dir opnsense nahelegen, da sieht man auch mehr.
https://opnsense.org/
kannst du auch live von CD aus laufen lassen zum testen nicht doof

Der Ipfire läuft auf einem Raspi und weil ich vor längerer Zeit schonmal IpCop im Betrieb hatte. Grundsätzlich komm ich damit ganz gut zurecht. Ich hab hier in zwei Netze aufgeteilt und mach OpenVPN.
Jetzt noch meinen Router umzustellen war eigentlich nicht der Plan. Zumal ich nicht (mehr glaube), dass es daran liegt, nachdem ich den Fehler 481 gefunden hab. Oder doch?

[sukram]

Eigentlich ist SIP Error 481 eine Verbindung, die das Telefon nicht mehr offen hat, z.b. wegen Paketverlust.

Möglicherweise könnte das Telefon der Meinung sein, dass der Call nicht zur Registrierung passt. Ist die Telefonnummer in der Konfiguration exakt so eingegeben, mit +49 und ohne 0 vor der Ortsvorwahl? Ich habe bisher kein Snom in den Fingern gehabt, dafür aber Gigaset, Grandstream und co. Und das Web Interface war meist abenteuerlich schlecht...

Aber wenn ich den Paketmitschnitt so ansehe, dann ändert das MGW von O2 nach dem "Ringing" plötzlich den "To" Header und verschluckt den @sip.alice... Host-Teil. Kann durchaus sein, dass das dem Snom nicht schmeckt.

[duese]

Das Ding ist, ich hab noch keine Stelle im Snom gefunden, wo ich eine Telefonnummer einstellen kann. Der Nutzername besteht bei O2 zwar aus der Telefonnummer ohne +, bei Sipgate ist das ganz was anderes. Sipgate ändert aber auch das to: nicht.

Hmm, das ist ein wertvoller Hinweis mit der Änderung, das hab ich noch nicht gesehen. Das kann natürlich gut sein.

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

Code: Alles auswählen

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: DIE SCHEISSE GEHT!!!!!!!11111einseinself

Das ganze geht auch ohne Portweiterleitung und ohne Stun-Server. Ob das auch die DSL Zwangstrennung übersteht muss sich zeigen, wir werden sehen.

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

[duese]

Update: Ja, ein STUN-Server hilft nach der Zwangstrennung schnell wieder erreichbar zu sein (immer noch ohne Portweiterleitung...)