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

SPA 3000 hinter Bintec X.2300is zu 1und1

Dieses Thema im Forum "Linksys (VoIP)" wurde erstellt von bikerede, 30 Jan. 2005.

Status des Themas:
Es sind keine weiteren Antworten möglich.
  1. bikerede

    bikerede Neuer User

    Registriert seit:
    30 Jan. 2005
    Beiträge:
    15
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo,

    ich habe seit Samstag einen SPA 3000. Diesen habe ich exakt lt. FAQ Grundkonfiguration SPA 3000 eingestellt, am Router sind die notwendigen Portfreigeben (5060..5062, 16384...16482) gesetzt.
    Leider meldet sich der SPA bei 1und1 mit der internen IP an, obwohl auf der Infopage die korrekte IP angezeigt wird.

    Code:
    System started: ip@192.168.10.4, reboot reason:H0
            subnet mask:    255.255.255.0
            gateway ip:     192.168.10.1
            dns servers:    192.168.10.1 217.237.149.225
    IDBG: st-0
    [5060]STUN trying 0
    [5060]STUN trying 1
    [5060]STUN trying 0
    [5060]STUN trying 1
    [5060]STUN trying 2
    [5060]STUN trying 3
    [5060]STUN trying 4
    fs:10190:10201:65536
    fbr:1:0000:0000:14362:0006:0007:2.0.11(GWg)
    fhs:01:0:0000:upg:app:0:2.0.11(GWg)
    fhs:02:0:0001:upg:app:1:2.0.11(GWg)
    fhs:03:0:0002:upg:app:2:2.0.11(GWg)
    fhs:04:0:0003:upg:app:0:2.0.11(GWg)
    fhs:05:0:0004:upg:app:1:2.0.11(GWg)
    fhs:06:0:0005:upg:app:2:2.0.11(GWg)
    [5060]STUN trying 5
    [5060]STUN trying 6
    [5060]STUN trying 7
    [5060]STUN trying 8
    [5060]STUN trying 0
    RSE_DEBUG: reference domain:sip.1und1.de
    RSE_DEBUG: reference domain:sip.1und1.de
    [1:5061]->212.227.15.194:5060
    [1:5061]->212.227.15.194:5060
    REGISTER sip:sip.1und1.de:5061 SIP/2.0
    Via: SIP/2.0/UDP 192.168.10.4:5061;branch=z9hG4bK-5e0dc7e5;rport
    From: <sip:49xxxxxxxxxx@sip.1und1.de:5061>;tag=67bea4bbba8ee22bo1
    To: <sip:49xxxxxxxxxx@sip.1und1.de:5061>
    Call-ID: 74d668e5-b2e0dfd1@192.168.10.4
    CSeq: 1 REGISTER
    Max-Forwards: 70
    Contact: <sip:49xxxxxxxxxx@192.168.10.4:5061>;expires=3600
    Warning: 399 spa "Symmetric NAT Detected"
    User-Agent: Sipura/SPA3000-2.0.11(GWg)
    Content-Length: 0
    Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER
    Supported: 100rel, x-sipura
    
    
    
    [0]ExtIpChanged:0
    [0]ExtSipPortChanged:0
    [0]RegFail. Retry in 1200
    [1:5061]<<212.227.15.194:5060
    [1:5061]<<212.227.15.194:5060
    SIP/2.0 479 Please don't use private IP addresses
    Via: SIP/2.0/UDP 192.168.10.4:5061;branch=z9hG4bK-5e0dc7e5;rport=32800;received=
    217.238.104.54
    From: <sip:49xxxxxxxxxx@sip.1und1.de:5061>;tag=67bea4bbba8ee22bo1
    To: <sip:49xxxxxxxxxx@sip.1und1.de:5061>;tag=32e930bf0f1ed484d4a78699f4ad7c11.61
    d4
    Call-ID: 74d668e5-b2e0dfd1@192.168.10.4
    CSeq: 1 REGISTER
    Server: Sip EXpress router (0.8.14 (i386/linux))
    Content-Length: 0
    
    [1]ExtSipPortChanged:0
    RSE_DEBUG: unref domain, sip.1und1.de
    RSE_DEBUG: unref domain, sip.1und1.de
    RSE_DEBUG: last unref for domain sip.1und1.de
    RSE_DEBUG: reference domain:sip.1und1.de
    RSE_DEBUG: reference domain:sip.1und1.de
    [1:5061]->212.227.15.194:5060
    [1:5061]->212.227.15.194:5060
    NOTIFY sip:sip.1und1.de:5061 SIP/2.0
    Via: SIP/2.0/UDP 217.238.104.54:32810;branch=z9hG4bK-fdf8a70e;rport
    From: <sip:49xxxxxxxxxx@sip.1und1.de:5061>;tag=9411727b53c46f67o1
    To: <sip:sip.1und1.de:5061>
    Call-ID: fd61d30-760a3ffd@192.168.10.4
    CSeq: 6 NOTIFY
    Max-Forwards: 70
    Event: keep-alive
    User-Agent: Sipura/SPA3000-2.0.11(GWg)
    Content-Length: 0

    Trage ich die erhaltene IP unter SIP/externe IP ein, funktioniert alles, aber leider nur bis zur nächsten IP-Vergabe.

    besten Dank für die Hilfe
     
  2. exim

    exim Admin a.D.

    Registriert seit:
    27 Apr. 2004
    Beiträge:
    1,013
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    "NAT Mapping enable: yes"?
     
  3. bikerede

    bikerede Neuer User

    Registriert seit:
    30 Jan. 2005
    Beiträge:
    15
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ja, NAT MAPPING ist enable
     
  4. Netview

    Netview IPPF-Promi

    Registriert seit:
    1 Apr. 2004
    Beiträge:
    3,366
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    Dipl.-Inf.
    Ort:
    Westerwald
    Außer NAT wird auch der stun-server benötigt:
    stun.1und1.de:3478 und enablen!

    outbound-proxy abschalten und Feld leer lassen.
     
  5. bikerede

    bikerede Neuer User

    Registriert seit:
    30 Jan. 2005
    Beiträge:
    15
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo,

    habe ich lt. Forum schon alles so eingestellt. Offensichtlich wird ja auch die richtige IP in der Infoseite angezeigt, aber bei der Übermittlung nicht verwendet.
     
  6. Netview

    Netview IPPF-Promi

    Registriert seit:
    1 Apr. 2004
    Beiträge:
    3,366
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    Dipl.-Inf.
    Ort:
    Westerwald
    sind folgende Felder so eingestellt?

    EXT IP: <leer>
    NAT Keep Alive Intvl: 15
     
  7. bikerede

    bikerede Neuer User

    Registriert seit:
    30 Jan. 2005
    Beiträge:
    15
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo,
    ist alles so eingestellt, funktioniert nur leider nicht.
     
  8. bikerede

    bikerede Neuer User

    Registriert seit:
    30 Jan. 2005
    Beiträge:
    15
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo.
    hier noch ein Debug vom Router

    06:54:23 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
    :6437/217.238.106.158:32880 -> 217.237.149.225:53
    06:54:23 DEBUG/INET: dnsd: qry from 192.168.10.4:6437 id 1 "ntp1.belwue.de." A 1
    06:54:23 DEBUG/INET: dnsd: cache 129.143.2.23 for ntp1.belwue.de.
    06:54:23 DEBUG/INET: dnsd: rsp to 192.168.10.4:6437 id 1 "ntp1.belwue.de." A 1/0
    /0
    06:54:23 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
    :65385/217.238.106.158:32881 -> 129.143.2.23:123
    06:54:29 INFO/INET: NAT: refused incoming session on ifc 10001 prot 6 217.238.10
    6.158:135 <- 217.238.169.179:4472
    06:54:30 INFO/INET: NAT: refused incoming session on ifc 10001 prot 6 217.238.10
    6.158:135 <- 217.238.169.179:4472
    06:54:30 INFO/INET: NAT: refused incoming session on ifc 10001 prot 6 217.238.10
    6.158:135 <- 217.238.169.179:4472
    06:54:33 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
    :20460/217.238.106.158:32882 -> 217.237.149.225:53
    06:54:33 DEBUG/INET: dnsd: qry from 192.168.10.4:20460 id 1 "stun.1und1.de." A 1
    06:54:33 DEBUG/INET: dnsd: cache 212.227.15.200 for stun.1und1.de.
    06:54:33 DEBUG/INET: dnsd: rsp to 192.168.10.4:20460 id 1 "stun.1und1.de." A 1/0
    /0
    06:54:33 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
    :5060/217.238.106.158:32883 -> 212.227.15.200:3478
    06:54:33 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
    06.158:32883 <- 212.227.15.201:3479
    06:54:33 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
    06.158:32883 <- 212.227.15.201:3479
    06:54:33 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
    06.158:32883 <- 212.227.15.201:3479
    06:54:34 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
    06.158:32883 <- 212.227.15.201:3479
    06:54:35 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
    06.158:32883 <- 212.227.15.201:3479
    06:54:36 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
    06.158:32883 <- 212.227.15.201:3479
    06:54:38 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
    06.158:32883 <- 212.227.15.201:3479
    06:54:39 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
    06.158:32883 <- 212.227.15.201:3479
    ropo:> debug all
    07:01:00 DEBUG/INET: NAT: delete session on ifc 10001 prot 17 217.238.106.158:10
    26/217.238.106.158:32889 <-> 217.237.149.225:53
    07:01:01 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
    :31609/217.238.106.158:32890 -> 217.237.149.225:53
    07:01:01 DEBUG/INET: dnsd: qry from 192.168.10.4:31609 id 1 "ntp1.belwue.de." A
    1
    07:01:01 DEBUG/INET: dnsd: cache 129.143.2.23 for ntp1.belwue.de.
    07:01:01 DEBUG/INET: dnsd: rsp to 192.168.10.4:31609 id 1 "ntp1.belwue.de." A 1/
    0/0
    07:01:01 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
    :14742/217.238.106.158:32891 -> 129.143.2.23:123
    07:01:03 INFO/INET: NAT: refused incoming session on ifc 10001 prot 6 217.238.10
    6.158:135 <- 217.238.25.243:2998
    07:01:03 INFO/INET: NAT: refused incoming session on ifc 10001 prot 6 217.238.10
    6.158:135 <- 217.238.25.243:2998
    07:01:04 INFO/INET: NAT: refused incoming session on ifc 10001 prot 6 217.238.10
    6.158:135 <- 217.238.25.243:2998
    07:01:06 DEBUG/INET: NAT: delete session on ifc 10001 prot 6 192.168.10.5:4157/2
    17.238.106.158:33313 <-> 217.160.220.106:80
    07:01:06 DEBUG/INET: NAT: delete session on ifc 10001 prot 6 192.168.10.5:4162/2
    17.238.106.158:33318 <-> 195.126.99.94:80
    07:01:11 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
    :28489/217.238.106.158:32892 -> 217.237.149.225:53
    07:01:11 DEBUG/INET: dnsd: qry from 192.168.10.4:28489 id 1 "stun.1und1.de." A 1
    07:01:11 DEBUG/INET: dnsd: fwd 192.168.10.4:28489 id 1 to 217.237.149.225:53 id
    19048 "stun.1und1.de." A
    07:01:11 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 217.238.106.
    158:1026/217.238.106.158:32893 -> 217.237.149.225:53
    07:01:11 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
    :5060/217.238.106.158:32894 -> 212.227.15.200:3478
    07:01:11 DEBUG/INET: dnsd: rsp from 217.237.149.225:53 id 19048 "stun.1und1.de."
    A 0 1/0/0
    07:01:11 INFO/INET: dnsd: cache add 212.227.15.200 for stun.1und1.de.
    07:01:11 DEBUG/INET: dnsd: rsp to 192.168.10.4:28489 id 1 "stun.1und1.de." A 1/0
    /0
    07:01:11 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
    06.158:32894 <- 212.227.15.201:3479
    07:01:11 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
    06.158:32894 <- 212.227.15.201:3479
    07:01:11 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
    06.158:32894 <- 212.227.15.201:3479
    07:01:12 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
    06.158:32894 <- 212.227.15.201:3479
    07:01:12 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
    06.158:32894 <- 212.227.15.201:3479
    07:01:13 DEBUG/IPSEC: IKE_INVALID_COOKIE: 19300422003257: Source addr:0.0.0.0
    Destination addr:212.185.162.10
    07:01:14 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
    06.158:32894 <- 212.227.15.201:3479
    07:01:15 INFO/INET: NAT: refused incoming session on ifc 10001 prot 6 217.238.10
    6.158:135 <- 217.238.30.61:3989
    07:01:15 DEBUG/INET: NAT: delete session on ifc 10001 prot 17 192.168.10.4:5061/
    217.238.106.158:32879 <-> 212.227.15.194:5060
    07:01:15 DEBUG/INET: NAT: delete session on ifc 10001 prot 17 192.168.10.4:5060/
    217.238.106.158:32878 <-> 212.227.15.194:5060
    07:01:16 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
    06.158:32894 <- 212.227.15.201:3479
    07:01:16 INFO/INET: NAT: refused incoming session on ifc 10001 prot 6 217.238.10
    6.158:135 <- 217.238.30.61:3989
    07:01:17 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
    06.158:32894 <- 212.227.15.201:3479
    07:01:17 DEBUG/INET: NAT: delete session on ifc 10001 prot 17 192.168.10.4:31609
    /217.238.106.158:32890 <-> 217.237.149.225:53
    07:01:18 INFO/INET: NAT: refused incoming session on ifc 10001 prot 6 217.238.10
    6.158:135 <- 217.238.30.61:3989
    07:01:19 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 217.238.1
    06.158:32894 <- 212.227.15.201:3479
    07:01:20 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
    :5060/217.238.106.158:32895 -> 212.227.15.201:3479
    07:01:20 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
    :39800/217.238.106.158:32896 -> 217.237.149.225:53
    07:01:20 DEBUG/INET: dnsd: qry from 192.168.10.4:39800 id 1 "sip.1und1.de." A 1
    07:01:20 DEBUG/INET: dnsd: cache 212.227.15.194 for sip.1und1.de.
    07:01:20 DEBUG/INET: dnsd: rsp to 192.168.10.4:39800 id 1 "sip.1und1.de." A 1/0/
    0
    07:01:20 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
    :5060/217.238.106.158:32897 -> 212.227.15.194:5060
    07:01:20 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 192.168.10.4
    :5061/217.238.106.158:32898 -> 212.227.15.194:5060
    07:01:31 DEBUG/INET: NAT: delete session on ifc 10001 prot 17 192.168.10.4:14742
    /217.238.106.158:32891 <-> 129.143.2.23:123
     
  9. RB

    RB Aktives Mitglied

    Registriert seit:
    22 Juni 2004
    Beiträge:
    1,311
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Selbständiger Bitbeißer
    Ort:
    40883 Ratingen
    Moin!

    Zu den Sipuras kann ich nichts sagen, aber meinen Senf zu dem syslog-Mitschnitt abegeben...

    Also aus meiner Sicht sieht das alles soweit OK aus.

    Wie aus dem Protokoll zu erkennen ist, läßt der Bintec die Antworten vom Zwillings-STUN-Server (Source Port 3479) nicht durch
    Die Antwort vom Haupt-STUN-Server kommt anscheinend ja durch, da keine Beschwerden zu sehen sind. Ein Stück weiter unten greift der STUN-Algorithmus vom Sipura dann selbst auf den Zwillings-Server zu
    Auch da kommen keine Fehler, also wird die Antwort dann wohl durchkommen. Das sollte eigentlich ausreichen, damit der STUN-Algorithmus den Typ der Firewall erkennt. Die externe IP-Adresse muß er auf jeden Fall mitgekriegt haben.

    Ich hab's bei mir mit WinStun (winziges kleines Hilfsprogrämmchen zum STUN-Test) mal ausprobiert: Er sagt: "Symmetric Firewall" und meine externe IP-Adresse. Sollte also eigentlich zumindest dafür klappen...

    Ich habe übrigens kein Port-Forwarding für 3478+3479 eingerichtet, damit die STUN-Tests nicht verfälscht werden.

    Wenn die IP-Adresse trotzdem nicht stimmt, kann das Problem eigentlich nur im Sipura selbst irgendwo liegen.
     
  10. bikerede

    bikerede Neuer User

    Registriert seit:
    30 Jan. 2005
    Beiträge:
    15
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo,
    besten Dank für die Info; ich selbst habe auch den Port3478/9 auf dem Router nicht eingerichtet.
    Woran kann es denn jetzt noch liegen?
     
  11. bikerede

    bikerede Neuer User

    Registriert seit:
    30 Jan. 2005
    Beiträge:
    15
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo,
    ich habe den Router mit WinStun getestet:

    Symetric - VOIP will NOT work
    Does not preserve port number
    Does not supports hairpin of media
    Public IP address: xxx.238.106.xxx

    Liegt hier das Problem?
     
  12. RB

    RB Aktives Mitglied

    Registriert seit:
    22 Juni 2004
    Beiträge:
    1,311
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Selbständiger Bitbeißer
    Ort:
    40883 Ratingen
    Wenn die Public IP Address stimmt, sollte das eigentlich reichen. Bei mir kommt exakt die gleiche Aussage über die Firewall (könnte daran liegen, daß ich auch einen Bintec-Router habe :wink: )

    Sowohl mein Cisco-Telefon, als auch SIPPS / X-Lite haben schon damit funktioniert (z.Z. telefoniere ich nur noch über das Cisco). Ich habe auch nur brav meine Port-Forwardings für SIP- und RTP-Ports gemacht, sonst nichts in der Richtung. Ach doch: Weil PURtel etwas anders als andere mit den Ports umgeht, habe ich in den NAT-Einstellungen auch von drinnen nach draußen den SIP-Port festgenagelt. Soll heißen, daß der externe Port für 5060/UDP auch 5060/UDP ist, und kein zufällig gewählter, wie für NAT sonst üblich. Das war aber, wie gesagt, nur für PURtel nötig.

    Ich vermute eher, daß der Sipura aus irgendwelchen Gründen nicht damit zufrieden ist, daß es diese Art Firewall ist. Eine weitere Möglichkeit wäre natürlich, daß der 1und1-STUN-Server sich irgendwie anders verhält, als erwartet. Schon mal irgendeinen anderen versucht?

    Ansonsten müssen die Sipura-Cracks jetzt hier was zu sagen...
     
  13. bikerede

    bikerede Neuer User

    Registriert seit:
    30 Jan. 2005
    Beiträge:
    15
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo,

    habe soeben larry.gloo.net getestet, gleicher Fehler.
    Da, wie im obersten Log aufgeführt, mein Adapter versucht, sich mit der internen IP sich bei sip.... anzumelden, kann es doch nicht reichen, obwohl sie ja auf der Infopage eangezeigt wird.
     
  14. bikerede

    bikerede Neuer User

    Registriert seit:
    30 Jan. 2005
    Beiträge:
    15
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo,
    ich habe mein Problem an Bintec weitergeleitet; mal sehen,ob der kostenlose First-Level-Support hilft.
     
  15. RB

    RB Aktives Mitglied

    Registriert seit:
    22 Juni 2004
    Beiträge:
    1,311
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Selbständiger Bitbeißer
    Ort:
    40883 Ratingen
    @bikerede
    Wie gesagt, ich denke nicht, daß das ein Bintec-Problem sein kann! Bei mir kommen die gleichen Meldungen und Zustände, aber es funktioniert halt trotzdem. Der wesentliche Unterschied ist, daß ich keinen Sipura habe. Ich denke mal, wenn schon, sollte man bei Sipura nachfragen.

    Der Router macht, was er soll: Unerwünschten bzw. unerwarteten Traffic blocken. Andere Wünsche müssen ihm kundgetan werden.
     
  16. bikerede

    bikerede Neuer User

    Registriert seit:
    30 Jan. 2005
    Beiträge:
    15
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo,
    nach mehreren Rückfragen bei Bintec habe ich letztendlich die Aussage erhalten, das dies der Router noch nicht kann; ev. ist im Laufe des Jahres mit dieser Funktion zu rechnen. Für einen doch in der "höheren" Region angesiedelten Router ist dies doch wohl eine sehr unbefriedigende Antwort.
    Der Zustand beim SPA ist unverändert, ich trage täglich die neue IP von Hd. ein.
     
  17. RB

    RB Aktives Mitglied

    Registriert seit:
    22 Juni 2004
    Beiträge:
    1,311
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Selbständiger Bitbeißer
    Ort:
    40883 Ratingen
    Was soll er denn nun nicht können?
    Und mit welcher Funktion soll eventuell im Laufe des Jahres zu rechnen sein?

    Wenn das Sipura nicht in der Lage ist, nach einer STUN-Abfrage über eine symmetrische NAT die öffentliche IP-Adresse korrekt einzutragen, kann das doch nicht Aufgabe des Routers sein, dem die Arbeit abzunehmen. Die Erkennung der Adresse scheint ja zu funktionieren. Wie Du schreibst, steht sie ja in der Übersicht drin. Wenn sie dann trotzdem nicht verwendet wird, ist das ja wohl eine Macke beim Sipura.

    Das scheint jedenfalls das Problem zu sein, soweit ich das bisher rauslesen konnte.

    Mein 7960 funktioniert jedenfalls problemlos. SIPPS und X-Lite/X-Pro ebenfalls. Nur SJPhone habe ich mit genau den gleichen Effekten wie bei Dir mit dem Sipura nicht ans Laufen bekommen, was ja wohl darauf hindeutet, daß es unterschiedliche Implementationen der STUN-Abfragen gibt. Die eine Variante funktioniert, die andere eben nicht...

    Nebenbei bemerkt: im Business-Bereich gilt SIP immer noch häufig als "Spielkram" (warum auch immer). Dort wird nach wie vor eher auf H.323 gesetzt. Und dafür haben zumindest die 1200er dann auch konsequenterweise einen Gatekeeper implementiert. Wenn die Akzeptanz von SIP im Business-Umfeld steigt (was ja der Fall zu sein scheint), werden die wahrscheinlich auch für SIP entsprechende Hilfen ( Proxy? ) einbauen.
     
  18. bikerede

    bikerede Neuer User

    Registriert seit:
    30 Jan. 2005
    Beiträge:
    15
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo,
    gemeint war, daß ein Unterstützung für STUN in der Firmware vorgesehen ist. Leider war bei Bintec nicht mehr zu erfahren, da alle kostenlosen Anfragen über den Firstlevelsupport erfolgen müssen; diese aber meine Anfragen per Mail nicht beantworten.
    Zurück zu meinem Problem: Mittlerweilen habe ich keinen Ansatz mehr zur Lösung. Fakt ist, daß SIP ohne Probleme nach einem manuellen Eintrag funktioniert.
    Sipura habe ich auch unter support@sipura.com angeschrieben, aber keinerlei Antwort erhalten. Gibt es hier ev. einen anderen Weg?
    Da lt. Forum der SPA 2000 hinter einem X.1200 funktioniert, habe ich mal meine Firmware auf die 6er Version zurückgesetzt, aber auch hier keine Änderung.
    Gibt es ev. eine andere Möglichkeit dem SPA meine IP zu übermitteln, da ich dyndns benutze?
     
  19. bikerede

    bikerede Neuer User

    Registriert seit:
    30 Jan. 2005
    Beiträge:
    15
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo,
    Problem erledigt; habe soeben eine neue Firmware 2.0.13 aufgespielt.
    Nach einer ersten Fehlregistrierung erfolgt nach 30s eine fehlerfreie Anmeldung. Dieser Zustand bleibt auch nach einem Neustart von Router und/oder SPA erhalten, hoffentlich sehr sehr lange.
     
  20. bikerede

    bikerede Neuer User

    Registriert seit:
    30 Jan. 2005
    Beiträge:
    15
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
     
Status des Themas:
Es sind keine weiteren Antworten möglich.