Hallo Forum, vorgestern habe ich von Sipgate den -- nicht vorkonfigurierten! -- ATA-468 bekommen, den ich im Clientbetrieb hinter einer Firewall hinter einem Router betreibe. Die Firmware habe ich (erfolgreich :wink: ) aktualisiert, es ist jetzt die 1.0.5.9. Mein Problem: ich kann wunderbar über Sipgate ins Festnetz telefonieren; bei einkommenden Rufen wird dieser zwar signalisiert, es kommt aber keine Sprachverbindung zustande. Meine Einstellungen: - ankommende Pakete aus den Netzen von Sipgate DE und Sipgate UK (Dankeschön an das Forum hier!) sind freigegeben, sowohl auf dem Router als auch auf der Firewall - die Ports (udp/5061 SIP und udp/5005-5007 RTP) sind auf die NAT-IP des ATA weitergeleitet (es geht mit 5060 und 5004 auch nicht) - der ATA ist mit SIP Server: sipgate.de, SIP Proxy: sipgate.de, Codec: PCMA (1-7), STUN Server: stun.sipgate.net:10000 und den Ports 5061/5005 konfiguriert - der ATA erhält per DHCP jedesmal dieselbe fixe IP-Adresse, die auch in der Firewall genattet wird Mit X-Lite (Konfiguration: Ports udp/5062 SIP und udp/5008 RTP) funktioniert es auch eingehend ohne Probleme. Der Unterschied: Mit X-Lite sieht ein eingehender Verbindungsaufbau etwa so aus: INVITE TRYING RINGING OK RTP... ... ... RTCP... RTP... ... ... usw. Mit dem ATA aber anders: INVITE TRYING RINGING udp/5004 vom ATA zu stun1.sipgate.net:10000 (Audio auf den STUN-Server???) Antwort von stun1.sipgate.net:10000 auf ATA:5004 OK RTP... ... ... kein RTCP... RTP... ... ... Meine NAT-Tabelle sieht demnach nach einem Anruf auf X-Lite so aus: Code: Cisco1721#sho ip nat trans Pro Inside global Inside local Outside local Outside global udp 80.140.97.44:45016 172.16.73.101:45016 217.10.79.3:10000 217.10.79.3:10000 udp 80.140.97.44:5062 172.16.73.101:5062 217.10.79.9:5060 217.10.79.9:5060 udp 80.140.97.44:5008 172.16.73.101:5008 217.10.66.11:18798 217.10.66.11:18798 icmp 80.140.97.44:5008 172.16.73.101:5008 217.10.66.11:18798 217.10.66.11:18798 udp 80.140.97.44:5009 172.16.73.101:5009 217.10.66.11:18799 217.10.66.11:18799 Cisco1721# nach einem Anruf auf dem ATA aber so: Code: Cisco1721#sho ip nat trans Pro Inside global Inside local Outside local Outside global udp 80.140.113.212:5061 172.16.73.111:5061 217.10.79.9:5060 217.10.79.9:5060 udp 80.140.113.212:5005 172.16.73.111:5005 217.10.79.2:10000 217.10.79.2:10000 udp 80.140.113.212:1000 172.16.73.111:1000 217.10.79.2:10000 217.10.79.2:10000 Cisco1721# Es wäre ganz toll, wenn mir jemand einen Tip in die richtige Richtung geben könnte! Tausend Dank!
Du solltest grundsätzlich die Ports am ATA so lassen, wie sie vorgegeben sind. Die Ports 5004-5007, 5060 und 10000 müssen zur IP des ATAs geroutet werden. Mit DMZ funktioniert es meistens nicht. Und wenn Du schon eigene Ports vegeben mußt, dann solltest Du darauf achten, keine Port-Überschneidungen zu verursachen. Also wenn Du nicht den Port 5060 verwendest, solltest Du mit 5062 weitermachen. Und wenn Du nicht 5004 verwendest, solltest Du mit 5008 weitermachen. Obwohl es eigentlich KEINEN Grund gibt, die vorgegebenen Ports zu ändern. Damit kannst Du sogar mehrere Geräte mit gleicher Port-Konfiguration in einem Netzwerk hinter dem Router betreiben - STUN sei Dank ! Und was meintest Du eigentlich mit "Audio" auf den STUN-Server ?
Re: eing.: Klingelton, keine Sprache; ausg. alles OK (Sipgat Hi, danke für Deine Antwort. Ich habe die Ports jeweils um eins erhöht, denn a) und b) soll noch ein zweiter Adapter angeschlossen werden, wenn der erste eventuell mal funktioniert, wie er soll. Port 5004 ist auf dem ATA momentan als RTP-Port konfiguriert. Der ATA schickt aber zwischen 'ringing' und 'ok' ein Paket an den STUN-Server, Port 10000, und zwar von Port 5004 aus.
ja - und ich sage Dir, Du DARFST nicht um EINS erhöhen, sondern in den von mir angegebenen Schritten. Und außerdem fehlen in Deiner NAT-Tabelle die RTP/RTCP-Ports. Nimm einfach die Standardports 5004-5007, 5060, 10000 und forwarde die auf Deinen ATA - und Du wirst sehen, daß alles funktioniert (ich spreche aus der Erfahrung von über 200 in Betrieb genommenen ATAs in verschiedensten Umgebungen). Und probiere bitte NICHT, gleichzeitig XLITE zu betreiben. Gute Nacht - ich gehe jetzt erstmal schlafen.
Hi, warum sollte ich nicht um eins erhöhen dürfen? Noch betreibe ich ja nur ein einziges VoIP-Gerät gleichzeitig. Siehe unter anderem auch hier: http://www.ip-phone-forum.de/forum/viewtopic.php?t=1954#16616 Mit der NAT-Tabelle hatte ich mich vielleicht etwas unglücklich ausgedrückt -- was oben angezeigt wird, sind die Einträge der NAT-Tabelle, die in Benutzung sind. Unter anderem ist daraus zu erkennen, daß bei der Verwendung von X-Lite der RTP-Stream funktioniert, bei späterer, nicht gleichzeitiger Verwendung des ATA nicht. Die eigentliche Konfiguration nach Deinem Vorschlag, um zwei zu erhöhen, sieht so aus: Code: ip nat inside source static udp 172.16.73.111 5062 interface Dialer10 5062 ip nat inside source static udp 172.16.73.111 5008 interface Dialer10 5008 ip nat inside source static udp 172.16.73.111 5009 interface Dialer10 5009 ip nat inside source static udp 172.16.73.111 5010 interface Dialer10 5010 ip nat inside source static udp 172.16.73.111 5011 interface Dialer10 5011 Es werden also die Ports 5062 und 5008 bis 5011 an den ATA weitergeleitet. Der ATA ist konfiguriert auf 5062 SIP und 5008 RTP. edit: fast vergessen: es funktioniert auch in dieser Konfiguration nicht. Danke für Deine Hilfe und gute Nacht!
Hallo nimsip schau mal auf der Configseite vom ATA nach welche Art von Firewall dort erkannt wird. Sollte Full cone NAT sein. Mit symetric NAT klappt das ganze nicht. Siehe hier: http://corp.deltathree.com/technology/nattraversalinsip.pdf Gruß Christian
Hallo, momentan bin ich (leider?) nicht zuhause, aber es ist tatsächlich so, daß X-Lite immer Full Cone erkennt, der ATA meistens Symmetric -- ganz selten auch mal Full Cone. Woran kann das liegen? Danke!
Hi, kann ich dir leider auch nicht so genau sagen. Kenn die Cisco teile nicht so genau. Bei mir war es die Firmware des Routers und das Update des BT auf 5.7. Christian
Hi, die Konfiguration des Routers ist für beide (PC (X-Lite) und ATA) identisch, bis auf die Ports. X-Lite erkennt die Verbindung als Port Restricted Cone NAT Firewall. Eingehende Anrufe funktionieren. ATA erkennt die Verbindung als Symmetric NAT, und es funktionieren nur ausgehende Anrufe. Was hat X-Lite, was der ATA nicht hat? :mrgreen:
So, ich habe ein bißchen weitergebastelt. Meine Konfiguration sieht jetzt -- entgegen der Signatur -- zum Testen erstmal so aus: Code: +--[Laptop] {Internet}--[Router]--[Hub]--| +--[ATA-468] | +--[Firewall]--{internes Netz} Der ATA bekommt natürlich eine in das Netz des Routers passende IP-Adresse zugewiesen. Am Hub hängt zusätzlich ein Laptop mit installiertem Ethereal, so kann ich den Transfer vom/zum ATA mitverfolgen. Der ATA ist für Port 5060 (SIP) und Port 5004 (RTP) konfiguriert. Software auf dem ATA: Program--1.0.4.68, Bootloader--1.0.0.16, HTML--1.0.0.31, VOC--1.0.0.5 Edit: Update auf: Program--1.0.5.9 Bootloader--1.0.0.18 HTML--1.0.0.37 VOC--1.0.0.6 - noch immer keine eingehenden Sprachverbindungen. Dabei ist mir folgendes aufgefallen: wenn ich aus dem Festnetz auf dem ATA anrufe, schickt der ATA icmp-unreachable-Pakete an den 'anrufenden' Server zurück; er sagt also, Port 5004 sei nicht erreichbar. Hier das erste RTP-Paket vom Server an den ATA: Code: Frame 7 (214 bytes on wire, 214 bytes captured) Arrival Time: Aug 6, 2004 21:36:45.319867000 Time delta from previous packet: 0.123239000 seconds Time relative to first packet: 15.240758000 seconds Frame Number: 7 Packet Length: 214 bytes Capture Length: 214 bytes Ethernet II, Src: 00:0b:5f:70:f1:3e, Dst: 00:0b:82:01:82:d1 Destination: 00:0b:82:01:82:d1 (Grandstr_01:82:d1) Source: 00:0b:5f:70:f1:3e (Cisco_70:f1:3e) Type: IP (0x0800) Internet Protocol, Src Addr: 217.10.66.11 (217.10.66.11), Dst Addr: 172.16.73.112 (172.16.73.112) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 200 Identification: 0x0000 (0) Flags: 0x04 .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 55 Protocol: UDP (0x11) Header checksum: 0x328f (correct) Source: 217.10.66.11 (217.10.66.11) Destination: 172.16.73.112 (172.16.73.112) User Datagram Protocol, Src Port: 15668 (15668), Dst Port: 5004 (5004) Source port: 15668 (15668) Destination port: 5004 (5004) Length: 180 Checksum: 0x605d (correct) Data (172 bytes) 0000 80 08 6b f5 00 00 00 a0 4f 15 a6 c4 54 54 54 54 ..k.....O...TTTT 0010 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT 0020 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT 0030 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT 0040 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT 0050 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT 0060 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT 0070 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT 0080 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT 0090 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTTTTTT 00a0 54 54 54 54 54 54 54 54 54 54 54 54 TTTTTTTTTTTT Hier die Antwort vom ATA: Code: Frame 8 (70 bytes on wire, 70 bytes captured) Arrival Time: Aug 6, 2004 21:36:45.321114000 Time delta from previous packet: 0.001247000 seconds Time relative to first packet: 15.242005000 seconds Frame Number: 8 Packet Length: 70 bytes Capture Length: 70 bytes Ethernet II, Src: 00:0b:82:01:82:d1, Dst: 00:0b:5f:70:f1:3e Destination: 00:0b:5f:70:f1:3e (Cisco_70:f1:3e) Source: 00:0b:82:01:82:d1 (Grandstr_01:82:d1) Type: IP (0x0800) Internet Protocol, Src Addr: 172.16.73.112 (172.16.73.112), Dst Addr: 217.10.66.11 (217.10.66.11) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 56 Identification: 0x104f (4175) Flags: 0x00 .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 250 Protocol: ICMP (0x01) Header checksum: 0x9fdf (correct) Source: 172.16.73.112 (172.16.73.112) Destination: 217.10.66.11 (217.10.66.11) Internet Control Message Protocol Type: 3 (Destination unreachable) Code: 3 (Port unreachable) Checksum: 0x4b2b (correct) Internet Protocol, Src Addr: 217.10.66.11 (217.10.66.11), Dst Addr: 172.16.73.112 (172.16.73.112) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 200 Identification: 0x0000 (0) Flags: 0x04 .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 55 Protocol: UDP (0x11) Header checksum: 0x328f (correct) Source: 217.10.66.11 (217.10.66.11) Destination: 172.16.73.112 (172.16.73.112) User Datagram Protocol, Src Port: 15668 (15668), Dst Port: 5004 (5004) Source port: 15668 (15668) Destination port: 5004 (5004) Length: 180 Checksum: 0x605d Warum ist das so? Hat jemand einen Tip?
Wäre prima, wenn jemand eine Antwort, einen Tip oder einen Vorschlag hätte. .. wenn ich bis Dienstag keine Lösung habe, kriegt Sipgate ein Paket von mir. :evil: :arrow: Änderungen, Debugs, Screenshots etc. könnt ihr von mir haben, soviel ihr wollt! Tausend Dank schonmal!
Hallo nimsip, Deine Hardwarekonfiguration finde ich schon etwas schräg. Wozu verwendest Du einen Hub? Bevor Du das Teil an Sipgate zurückschickst, verwende den ATA als Router und versuche dann erst mal, ob eingehende Anrufe klappen. Dann besorge Dir einen Switch anstatt nen Hub. Ich weiss z.B. nicht, wie sich SIP über nen Hub verhält, zumal der ATA einen 10MBit-Netzwerkanschluss hat. Switches sind dort unproblematischer. Es gibt nur eine Sache, wo der ATA486 als Router (noch) versagt: Port 80 wird nicht weitergereicht, ein Webserver hinter dem ATA486 funktioniert daher nicht. Um eine Fehlkonfiguration seitens des ATA486 auszuschliessen, sollte man erst einmal ihn "solo" testen. X-Lite verhält sich Fehlkonfigurationen seitens eines Routers toleranter. Wieso, weiss ich auch nicht. Viele Grüße, Jens
Hallo nimsip hast du schon mal versucht alle Ports von der Sipgate Ip durchzulassen. Ip-Range ist 217.10.79.3-217.10.79.9 Und schau mal ob dein Router einen Eintrag für Gaming Mode hat. Wenn ja einfach mal auf Enable stellen. Was anderes fällt mir jetzt auch nicht ein. Gruß Christian
Hi, Momentan zum Debuggen, ja. Normalerweise sieht die HW schon anders aus (siehe Signatur: {INET}-Rtr-FW-Clients/ATA). Ich habe das nur umgebastelt, um hundertprozentig sicher zu sein, daß mir die Firewall nicht dazwischenspuckt. Radio Erewan: "im Prinzip ja." Nur: ein (einfacher) Switch stellt eine 1-zu-1-Beziehung zwischen zwei Ports her, so daß man auf einem dritten Port nicht "mithören" kann. Ein Hub "verteilt" alles, was über einen Port läuft, an alle anderen Ports; nur so kann ich mit Ethereal (ein Netzwerkanalysator) die Pakete am Laptop auch sehen. Ansonsten verhalten sich Switch und Hub gleich: wie eine "Verteilersteckdose"; das darf und kann dem ATA nichts ausmachen. Desweiteren MUSS das Ding auch im Clientmodus laufen. Ich bin mir sicher, auch in den von betateilchen angesprochenen, erfolgreichen 200 ATA-Installationen wird sich die eine oder andere Clientinstallation finden. Das stört mich momentan nicht, aber danke, das wußte ich noch nicht. Ja, ich teste nur solo; entweder ATA oder X-Lite. Das Problem stellt sich momentan wie folgt dar: der Router reicht an Port 5004/udp (=RTP/Audio) adressierte Pakete an den ATA weiter, und der wiederum schickt "Port 5004? Gibt's hier nicht" zurück.
Jau. Auch die von Sipgate UK, welche eindeutig in der Überzahl sind: 12 permit ip 217.10.79.0 0.0.0.255 any (46 matches) 14 permit ip 217.10.66.0 0.0.0.255 any (2546 matches) Ich bitte Dich -- das ist ein Cisco! :wink: Nein, da gibt es keinen Gamingmode. Es ist aber durchaus möglich, einen Gamingmode bzw. eine "DMZ" nachzubilden. Manno! :cry: Dennoch tausend Dank!
Hallo, mit solo testen meinte ich, den ATA486 als Router zu benutzen . Da Du keinen Webserver hast, sind in diesem Fall eigentlich alle Probleme gelöst und du hast sogar anständigen QoS für Telefonie. Wenn es dann geht, ist der ATA schon mal unschuldig. Ok, das mit dem Hub zum sniffen habe ich nun auch verstanden . Gibts denn auch noch Probleme, wenn Du alles bis auf den Adapter an Deinem Router abstöpselst? Wenn ja: Scheiss Router :roll: . Mal gucken ob Du hier im Forum oder woanders Tipps und vielleicht ne aktuelle Firmware für den Router bekommst. Ich habe hier übrigends den ATA486 als Client laufen. Mein SMC-Router macht dort auch ein paar Zicken. Ansonsten klappts hier prima. Ich glaube trotz Deiner Analyse immer noch nicht, das der ATA486 im Eimer ist Weiterhin viel Erfolg bei der Fehlersuche, Jens PS. Und wenn es läuft, bitte hier melden, damit andere mit gleichen Problemen Bescheid wissen...
Neue Erkenntnis: es scheint unter Umständen tatsächlich in der NAT-Behandlung der SIP-Pakete durch den Router zu liegen: Mit dem ATA direkt an DSL: Code: Internet Protocol, Src Addr: 80.140.100.107 (80.140.100.107), Dst Addr: 217.10.79.9 (217.10.79.9) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Session Initiation Protocol Status-Line: SIP/2.0 200 OK Message Header Via: SIP/2.0/UDP 217.10.79.9;branch=z9hG4bKcfa2.ef9f10d6.2 Via: SIP/2.0/UDP 217.10.79.8;branch=z9hG4bKcfa2.64e206f5.0 Via: SIP/2.0/UDP 217.10.79.8;branch=z9hG4bKcfa2.54e206f5.0 Via: SIP/2.0/UDP 217.10.66.11:5060;branch=z9hG4bK3e531974 Record-Route: <sip:[called SIP ID]@217.10.79.9;ftag=as4022e77c;lr=on> Record-Route: <sip:[called SIP ID]@217.10.79.8;ftag=as4022e77c;lr=on> Record-Route: <sip:[called number]@217.10.79.8;ftag=as4022e77c;lr=on> From: "[calling number]" <sip:[calling number]@217.10.66.11>;tag=as4022e77c SIP Display info: "[calling number]" SIP from address: sip:[calling number]@217.10.66.11 SIP tag: as4022e77c To: <sip:[called number]@sipgate.net>;tag=0354c577371e9531 Call-ID: 68ef4c4940eab2da44fb34581b6c74a6@217.10.66.11 CSeq: 102 INVITE User-Agent: Grandstream HT486 1.0.5.9 Contact: <sip:[called SIP ID]@80.140.100.107> Mit dem ATA hinter dem Router: Code: Internet Protocol, Src Addr: 80.140.100.195 (80.140.100.195), Dst Addr: 217.10.79.9 (217.10.79.9) User Datagram Protocol, Src Port: 1026 (1026), Dst Port: 5060 (5060) Session Initiation Protocol Status-Line: SIP/2.0 200 OK Message Header Via: SIP/2.0/UDP 217.10.79.9;branch=z9hG4bK1dfe.3b8e3887.2 Via: SIP/2.0/UDP 80.140.100.195:1029;branch=z9hG4bK1dfe.35cc5a75.0 Via: SIP/2.0/UDP 80.140.100.195:1029;branch=z9hG4bK1dfe.25cc5a75.0 Via: SIP/2.0/UDP 80.140.100.195:1030;branch=z9hG4bK3e522478 Record-Route: <sip:[called SIP ID]@217.10.79.9;ftag=as1a77340a;lr=on> Record-Route: <sip:[called SIP ID]@80.140.100.195:1029;ftag=as1a77340a;lr=on> Record-Route: <sip:[called number]@80.140.100.195:1029;ftag=as1a77340a;lr=on> From: "[calling number]" <sip:[calling number]@80.140.100.195:1030>;tag=as1a77340a SIP Display info: "[calling number]" SIP from address: sip:[calling number]@80.140.100.195:1030 SIP tag: as1a77340a To: <sip:[called number]@sipgate.net>;tag=61b493d7337ee291 Call-ID: 24ce1f622c3ee529291a176b41cb9584@217.10.66.11 CSeq: 102 INVITE User-Agent: Grandstream HT486 80.140.100.195:1028 Contact: <sip:[called SIP ID]@80.140.100.195:1027> Wie man sieht, setzt der Router alles um, was auch nur im entferntesten einer IP-Adresse gleichkommt -- peinlicherweise auch den Firmwarestring; aus 1.0.5.9 wird meine externe IP-Adresse... :twisted: Wie für alle anderen 'Ersetzungen' auch, wird dann auch für den Firmwarestring gleich auch noch ein Port bereitgestellt: Code: Aug 9 01:58:39.913: NAT: Allocated Port for 1.0.5.9 -> 80.140.100.195: wanted 5060 got 1028 Mal abwarten, was Cisco dazu sagt.