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

[nimsip]

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:

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:

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!

 

[betateilchen]

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 ?

 

[nimsip]

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)

(es geht mit 5060 und 5004 auch nicht)

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.

 

[betateilchen]

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.

 

[nimsip]

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:

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!

 

[boarder212]

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

 

[betateilchen]

Einspruch !

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

 

[boarder212]

Bei meinem BT mit .5.7 klappt es nicht mit Symmetric NAT.

Ist aber doch ein Versuch wert.


Christian

 

[nimsip]

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!

 

[boarder212]

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

 

[nimsip]

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:

 

[nimsip]

So, ich habe ein bißchen weitergebastelt. Meine Konfiguration sieht jetzt -- entgegen der Signatur -- zum Testen erstmal so aus:

                             +--[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:

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:

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?

 

[nimsip]

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!

 

[Katzenjens]

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

 

[boarder212]

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

 

[nimsip]

Hi,

Hallo nimsip,

Deine Hardwarekonfiguration finde ich schon etwas schräg.

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.

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.

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.

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.

Das stört mich momentan nicht, aber danke, das wußte ich noch 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.

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.

 

[nimsip]

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

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)

Und schau mal ob dein Router einen Eintrag für Gaming Mode hat.
Wenn ja einfach mal auf Enable stellen.

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.

Was anderes fällt mir jetzt auch nicht ein.

Manno! :cry: Dennoch tausend Dank!

 

[Katzenjens]

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...

 

[nimsip]

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:

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: [email protected]
        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:

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: [email protected]
        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:

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.