.titleBar { margin-bottom: 5px!important; }

eing.: Klingelton, keine Sprache; ausg. alles OK (Sipgate)

Dieses Thema im Forum "Grandstream" wurde erstellt von nimsip, 2 Aug. 2004.

  1. nimsip

    nimsip Neuer User

    Registriert seit:
    1 Aug. 2004
    Beiträge:
    76
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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!
     
  2. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    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 ?
     
  3. nimsip

    nimsip Neuer User

    Registriert seit:
    1 Aug. 2004
    Beiträge:
    76
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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.
     
  4. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    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.
     
  5. nimsip

    nimsip Neuer User

    Registriert seit:
    1 Aug. 2004
    Beiträge:
    76
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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!
     
  6. boarder212

    boarder212 Neuer User

    Registriert seit:
    28 Juni 2004
    Beiträge:
    43
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
  7. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    Einspruch !

    Seit Firmware 1.0.5.7 funktionieren Grandstream-Geräte auch mit "Symmetric NAT"
     
  8. boarder212

    boarder212 Neuer User

    Registriert seit:
    28 Juni 2004
    Beiträge:
    43
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Bei meinem BT mit .5.7 klappt es nicht mit Symmetric NAT.

    Ist aber doch ein Versuch wert.


    Christian
     
  9. nimsip

    nimsip Neuer User

    Registriert seit:
    1 Aug. 2004
    Beiträge:
    76
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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!
     
  10. boarder212

    boarder212 Neuer User

    Registriert seit:
    28 Juni 2004
    Beiträge:
    43
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
     
  11. nimsip

    nimsip Neuer User

    Registriert seit:
    1 Aug. 2004
    Beiträge:
    76
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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:
     
  12. nimsip

    nimsip Neuer User

    Registriert seit:
    1 Aug. 2004
    Beiträge:
    76
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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?
     
  13. nimsip

    nimsip Neuer User

    Registriert seit:
    1 Aug. 2004
    Beiträge:
    76
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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!
     
  14. Katzenjens

    Katzenjens Mitglied

    Registriert seit:
    24 Mai 2004
    Beiträge:
    205
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    Wiesbaden
    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
     
  15. boarder212

    boarder212 Neuer User

    Registriert seit:
    28 Juni 2004
    Beiträge:
    43
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
     
  16. nimsip

    nimsip Neuer User

    Registriert seit:
    1 Aug. 2004
    Beiträge:
    76
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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." :D
    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.
     
  17. nimsip

    nimsip Neuer User

    Registriert seit:
    1 Aug. 2004
    Beiträge:
    76
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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!
     
  18. Katzenjens

    Katzenjens Mitglied

    Registriert seit:
    24 Mai 2004
    Beiträge:
    205
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    Wiesbaden
    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 :p

    Weiterhin viel Erfolg bei der Fehlersuche,
    Jens

    PS.
    Und wenn es läuft, bitte hier melden, damit andere mit gleichen Problemen Bescheid wissen...
     
  19. nimsip

    nimsip Neuer User

    Registriert seit:
    1 Aug. 2004
    Beiträge:
    76
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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.