VCM/SIP funktioniert nicht

[Tiffy]

Hallo,

ich versuche bis dato erfolglos die Registrierung einer SIP-Leitung mit einem LANCOM 1783VAW.

Zum Provider habe ich 2 VDSL-Verbindungen (2 VLANs) aufgebaut, eine für Internet, eine für VOIP mit unterschiedlichen Routing-Tags. Internet funktioniert problemlos.

Getestet wird die Verbindung mit einem Einzelaccount. Die vom Provider bereitgestellten Daten sind im VCM hinterlegt (SIP-Domäne, SIP-ID, Registrar, Proxy).

Folgende Daten liefert tr # call:

Code: Alles auswählen

[Callmanager] 2017/04/08 17:52:01,411 [DNS Resolver]: ExecuteDnsResolve   SrvString: _sip._udp.<SIP-Proxy-Server>,  IP: 0.0.0.0,  Status: 1
[Callmanager] 2017/04/08 17:52:01,411 [DNS Resolver]: ExecuteDnsResolve   SrvString: _sip._udp.<Registrar>,  IP: 0.0.0.0,  Status: 1
[Callmanager] 2017/04/08 17:52:01,411 [SIP-Provider] : -----[ registrarDnsUpdate  -  resolve failed!

Deutet das auf Probleme mit der Namensauflösung hin? Wo kann ich zur Lösung ansetzen?

[Jirka]

Hi,

mach mal ein

tr # dns

auf der Konsole.

Viele Grüße,
Jirka

[Tiffy]

Hi,

tr # dns liefert u. a.:

Code: Alles auswählen

...
[DNS] 2017/04/09 09:52:44,120
DNS Rx (intern): Src-IP <WAN-IP-Adr. (VDSL-Verbindung 2)>, RtgTag 2
Query Request: STD SRV for _sip._udp.<SIP-Proxy>
DnsGetDest: Match found: forwarding _sip._udp.<SIP-Proxy> to <Name der Gegenstelle VDSL-Verbindung 2>
Not found in local DNS database => forward to next server
...

tr # call liefert u. a.:

Code: Alles auswählen

...
[Callmanager] 2017/04/09 10:04:15,403 [DNS Resolver]: ExecuteDnsResolve   SrvString: _sip._udp.<Registrar>,  IP: 0.0.0.0,  Status: 1
[Callmanager] 2017/04/09 10:04:15,403 [SIP-Provider] : -----[ registrarDnsUpdate  -  resolve failed!
[Callmanager] 2017/04/09 10:04:15,403 [DNS Resolver]: ExecuteDnsResolve   SrvString: _sip._udp.<SIP-Proxy>,  IP: 0.0.0.0,  Status: 1
[Callmanager] 2017/04/09 10:04:24,380 [DNS Resolver]: ExecuteDnsResolve   SrvString: _sip._udp.<Registrar>  IP: <IP-Adr.>,  Status: 0
[Callmanager] 2017/04/09 10:04:24,380 [SIP-Provider] : -----[ registrarDnsUpdate  -  resolve done!
[Callmanager] 2017/04/09 10:04:24,380 [SIP-Provider] : -----[ setDnsRegistrarTransport -> IP:old=0.0.0.0,new=<IP-Adr.> Port:old=0,new=5060 m_disconnected:no
[Callmanager] 2017/04/09 10:04:24,380 [SIP-Provider] : -----[ setDnsRegistrarTransport -> Registrar-IP/Port changed: any calls:no
[Callmanager] 2017/04/09 10:04:24,380 [SIP-Provider] : -----[ setDnsRegistrarTransport -> change values and start registration
[Callmanager] 2017/04/09 10:04:24,381 [Transport] : cSipTransport::cSipTransport  this:089ccb80 :: register transport
[Callmanager] 2017/04/09 10:04:24,381 [Transport] :   cSipTransport::Connected  --  NewAddr: <WAN-IP-Adr.>
[Callmanager] 2017/04/09 10:04:24,381 [SIP-Provider] : -----[ UdpConnected for line "TNK" ->  m_disconnected:0,  OldIp: 0.0.0.0,  NewIp: <WAN-IP-Adr.>
[Callmanager] 2017/04/09 10:04:24,381 [SIP-Provider] : -----[ New IP  -->  Restart Line!
[Callmanager] 2017/04/09 10:04:24,381 [SIP-Provider] : -----[ restart  ->  name: <Registrar>
[Callmanager] 2017/04/09 10:04:25,400 [DNS Resolver]: ExecuteDnsResolve   SrvString: _sip._udp.<Registrar>,  IP: 0.0.0.0,  Status: 1
[Callmanager] 2017/04/09 10:04:25,400 [SIP-Provider] : -----[ registrarDnsUpdate  -  resolve failed!
[Callmanager] 2017/04/09 10:04:25,400 [DNS Resolver]: ExecuteDnsResolve   SrvString: _sip._udp.<SIP-Proxy>,  IP: 0.0.0.0,  Status: 1
[Callmanager] 2017/04/09 10:04:29,381 [Transport] :   cSipTransport::Connected  --  NewAddr: <WAN-IP-Adr.>
[Callmanager] 2017/04/09 10:04:29,381 [SIP-Provider] : -----[ UdpConnected for line "TNK" ->  m_disconnected:1,  OldIp: <WAN-IP-Adr.>,  NewIp: <WAN-IP-Adr.>
[Callmanager] 2017/04/09 10:04:33,437 [DNS Resolver]: ExecuteDnsResolve   SrvString: _sip._udp.<Registrar>,  IP: <IP-Adr.>,  Status: 0
[Callmanager] 2017/04/09 10:04:33,437 [SIP-Provider] : -----[ registrarDnsUpdate  -  resolve done!
[Callmanager] 2017/04/09 10:04:33,437 [SIP-Provider] : -----[ setDnsRegistrarTransport -> IP:old=<IP-Adr.>,new=<IP-Adr.> Port:old=5060,new=5060 m_disconnected:yes
[Callmanager] 2017/04/09 10:04:33,437 [SIP-Provider] : -----[ setDnsRegistrarTransport -> Registrar-IP/Port changed: any calls:no
[Callmanager] 2017/04/09 10:04:33,437 [SIP-Provider] : -----[ setDnsRegistrarTransport -> change values and start registration
[Callmanager] 2017/04/09 10:04:33,437 [Transport] : cSipTransport::cSipTransport  this:088ea540 :: register transport
[Callmanager] 2017/04/09 10:04:33,437 [Transport] : ~cSipTransport  this:089ccb80
[Callmanager] 2017/04/09 10:04:33,437 [Transport] :   cSipTransport::Connected  --  NewAddr: <WAN-IP-Adr.>
[Callmanager] 2017/04/09 10:04:33,437 [SIP-Provider] : -----[ UdpConnected for line "TNK" ->  m_disconnected:0,  OldIp: <WAN-IP-Adr.>,  NewIp: <WAN-IP-Adr.>
[Callmanager] 2017/04/09 10:04:33,438 [SIP-Provider] : ----- startRegistration 1  this:089f3220, Caller:00dc1854, LineName:TNK
[Callmanager] 2017/04/09 10:04:33,438 [SIP-Provider] : ----- startRegistration 2
[Callmanager] 2017/04/09 10:04:33,438 [SIP-Provider] : ----- startRegistration 3
[Callmanager] 2017/04/09 10:04:33,438 [SIP-Provider] : triggerPendingMessages
[Callmanager] 2017/04/09 10:04:33,438 [DNS Resolver]: ExecuteDnsResolve   SrvString: _sip._udp.<SIP-Proxy>,  IP: 0.0.0.0,  Status: 1
[Callmanager] 2017/04/09 10:04:35,438 [SIP-Provider] : ----- RegisterTimeout 1 -  isNotAvailable:0, this:089f3220, LineName:TNK
[Callmanager] 2017/04/09 10:04:35,438 [SIP-Provider] : ----- RegisterTimeout 2  -- eNaUnregister
[Callmanager] 2017/04/09 10:04:35,438 [SIP-Provider] : -----[ setRegistrationTransport -> IP:old=<IP-Adr.>,new=<IP-Adr.> Port:old=5060,new=5060
[Callmanager] 2017/04/09 10:04:35,438 [SIP-Provider] : cSipProviderLine::Unregister 1  CallId:<Rufnummer>-<SIP-Domäne>-c0a20e74@00a0572eaee5
[Callmanager] 2017/04/09 10:04:35,438 [SIP-CALL] : cSipCall constructor (type 2) --- call=089e6100, MediaStub=089e6518, SIP call-id=2308588917@00a0572eaee5
...

tr # sip-packet liefert:

Code: Alles auswählen

[SIP-Packet] 2017/04/09 10:50:46,910 [PACKET] : 
Sending datagram with length 572 from <WAN-IP-Adr.>:9401 to <IP-Adr.>:5060 using UDP (Rtg-Tag:2)
REGISTER sip:<SIP-Domäne> SIP/2.0\r\n
Via: SIP/2.0/UDP <WAN-IP-Adr.>:9401;branch=z9hG4bK-2fad62be-511e1477\r\n
From: <sip:<Rufnummer>@<SIP-Domäne>>;tag=-1643225522-611463049\r\n
To: <sip:<Rufnummer>@<SIP-Domäne>>\r\n
Call-ID: <Rufnummer>@<SIP-Domäne>-c0a20e74@00a0572eaee5\r\n
CSeq: 1 REGISTER\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS, PRACK, UPDATE, SUBSCRIBE\r\n
Max-Forwards: 70\r\n
Contact: <sip:<Rufnummer>@<WAN-IP-Adr.>:9401;transport=UDP>\r\n
Expires: 480\r\n
User-Agent: LANCOM 1783VAW (over ISDN) / 9.24.0212 / 07.03.2017\r\n
Content-Length: 0\r\n
\r\n

[Jirka]

Hi,

der SIP-Packet-Trace geht nicht weiter?
Stimmt die IP, wo der LANCOM das Paket hinschickt?
Dann würde ich als nächstes einen Ethernet-Trace machen, um zu schauen, ob das Paket VLAN-getaggt den LANCOM-Router verlässt. Die WAN-Verbindung war doch VLAN-getaggt? Ich würde den Ethernet-Tace aber auf die Ziel-IP des Providers filtern:
tr # eth @ <IP-Adr.>

Viele Grüße,
Jirka

[Tiffy]

Hi Jirka,

Ja, nach CSeq: 1... ist (leider) Schluss.

Ich habe zwischenzeitlich die Kommunikation über die entsprechende Route getestet, ein

Code: Alles auswählen

tr # ip-router @  <default route voip>

liefert als Ergebnis keine Kommunikation, auf die <default route internet> schon. Und ja, VLAN ist eingestellt und unterschiedliche Routing-Tags (0 (internet) und 2 (voip)) sind gesetzt.

Auch

Code: Alles auswählen

tr # eth @ <IP-Adr.>

liefert als Ergebnis keine Kommunikation.

VG

[Tiffy]

Hi,

nochmal zu später Stunde. Ich bekomme doch noch etwas Kommunikation zu sehen, allerdings funktioniert VoIP leider nicht:

Code: Alles auswählen

tr # vdsl-data @ <IP-Adr.>

[VDSL-DATA] 2017/04/09 22:41:25,960
Sent 620 byte Ethernet packet via VDSL:
-->IEEE 802.3 Header
Dest                : <MAC-Adr.> (VRRP(?) fd)
Source              : <Meine MAC-Adr.> (LANCOM(local-1) 2e:ae:e5)
Type                : 802.1p/q VLAN
-->802.1p/q VLAN Header
VLAN Id             : <VOIP-VLAN-ID>
VLAN Prio           : 6
VLAN CFI            : 0
Type                : IPv4
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0xc0) (Precedence 6) / (DSCP CS6)
Total length        : 602
ID                  : 15054
Fragment            : Offset 0
TTL                 : 60
Protocol            : UDP
Checksum            : 16073 (OK)
Src Address         : <Meine WAN-IP, VDSL2-Verbindung-2>
Dest Address        : <IP-Adr.>
-->UDP Header
Src Port            : 10046
Dest Port           : SIP
Length              : 582
Checksum            : 5556 (OK)
-->SIP Packet
Header              : <Meine Registrierungsinformationen mit CSeq: 1 REGISTER...>


[VDSL-DATA] 2017/04/09 22:41:26,378
Received 98 byte Ethernet packet via VDSL:
IPv4 Hdr Checksum   : OK
-->IEEE 802.3 Header
Dest                : <Meine MAC-Adr.> (LANCOM(local-1) 2e:ae:e5)
Source              : <MAC-Adr.> (VRRP(?) fd)
Type                : 802.1p/q VLAN
-->802.1p/q VLAN Header
VLAN Id             : <VOIP-VLAN-ID>
VLAN Prio           : 6
VLAN CFI            : 0
Type                : IPv4
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0xc0) (Precedence 6) / (DSCP CS6)
Total length        : 80
ID                  : 0
Fragment            : Offset 0
TTL                 : 255
Protocol            : ICMP
Checksum            : 36936 (OK)
Src Address         : <Gateway aus dem Netz der VDSL2-Verbindung-2>
Dest Address        : <Meine WAN-IP, VDSL2-Verbindung-2>
-->ICMP Header
Msg                 : network unreachable
Checksum            : 42636 (OK)
Unused              : 0
Next-Hop MTU        : 0
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0xc0) (Precedence 6) / (DSCP CS6)
Total length        : 602
ID                  : 15054
Fragment            : Offset 0
TTL                 : 59
Protocol            : UDP
Checksum            : 16329 (OK)
Src Address         : <Meine WAN-IP, VDSL2-Verbindung-2>
Dest Address        : <IP-Adr.>
-->UDP Header
Src Port            : 10046
Dest Port           : SIP
Length              : 582
Checksum            : 5556 (wrong, should be 16193)
-->SIP Packet
Header              : REGISTER sip:<Name der SIP-Domäne unvollständig und dann Schluss>

VG

[Jirka]

Hi Tiffy,

ach dass Du das interne VDSL-Modem nutzt, war mir nicht klar, ich habe mir eingebildet, dass Du ein externes VDSL-Modem hast. Deswegen hatte ich Dir den Ethernet-Trace vorgeschlagen, sorry. Aber Du hast ja richtig weitergedacht und bist beim VDSL-Data-Trace gelandet.

Ja, im letzten Paket oben sieht man ja sehr schön das "network unreachable" was vom Provider kommt. Da müsstest Du jetzt drüber nachdenken. Ich kann es nicht wirklich, da ich weder weiß, um welchen Provider es sich hier handelt, noch an welche IP-Adresse das Paket ging.

Viele Grüße,
Jirka

P.S.: Auch nochmals die Frage: Stimmt die IP-Adresse, an die der LANCOM-Router das REGISTER schickt?

[Tiffy]

Guten Morgen Jirka,

ja, das "network unreachable" macht mich fertig. Mit der vom Provider bezogenen Fritzbox (7490) funktioniert VoIP. Die bekannten Einstellungen beim 1783vaw stimmen auch mit denen in der Fritzbox überein. Der Provider ist die TNK (Thüringer Netkom mit Thueringendsl). Kann ich der mitgelieferten Fritzbox ggf. noch mehr Verbindungsparameter entlocken, als bisher bekannt?

VG

[Jirka]

Guten Morgen Tiffy,

hmm. Mit aktueller Firmware der FRITZ!Box lässt sich da recht wenig machen, weil Telnet da gesperrt ist. Im Prinzip verbleiben zwei Ansätze: Erstens, Du überprüfst noch mal die Zuordnung (!) der Daten von der FRITZ!Box zum LANCOM. Die Bezeichnung der entsprechenden Felder ist nicht gleich. Du kannst es beim LANCOM auch nur mal mit der SIP-Domäne probieren. Auch könntest Du mal ein 'nslookup -type=srv _sip._udp.<SIP-Domäne>.de' auf der Konsole von Windows probieren und auch jeweils die IP-Adresse(n) zur Kenntnis nehmen (und ggf. vergleichen mit dem, was Du bisher beobachtet hast). Zweitens kannst Du an der FRITZ!Box einen Trace auf WAN-Seite machen, den mit Wireshark anschauen und dann auswerten (das Trace-GUI in der FRITZ!Box müsstest Du glaube ich unter http://fritz.box/html/support.html finden).
Mit dem Provider habe ich noch keine Erfahrung, ist mir noch nicht begegnet.

Viele Grüße,
Jirka

[Tiffy]

Hi Jirka,

ich bleibe dran und werde erstmal notgedrungen zuück zur Fritzbox wechseln. Die öff. IP-Adr., an die der LANCOM das Register versendet ist nicht in dem Netz, an das der Lancom über die zweite VDSL2-Verbindung angebunden wird und das Gateway in diesem Netz kann damit nichts anfangen.

Nochmal zusammengefasst ist die Konstellation so: Es gibt vom Provider 2 VLANS, eines für Internet und eines für VOIP. Der Lancom hat jeweils eine VDSL2-Verbindung aufgebaut und ist mit den VLANs verbunden, die Adresszuweisung klappt auch per DHCP. Der Kommunikationslayer ist jeweils DHCPOEOV. Für jedes Netz habe ich eine Default-Route eingestellt und mit Routing-Tags unterschieden. Die Kommunikation über das Internet-VLAN funktioniert problemlos, die Kommunikation über das VoIP-VLAN klappt nicht.

VG

[Tiffy]

Hi,

mal ein neuer, kurzer Zwischenstand: Nach dem Deaktivieren der Leitungsüberwachung wechselt die Leitung nun in den Zustand bereit. Aber das Telefonieren klappt trotzdem nicht. Nachdem der Ruf abgesetzt wird vom Analogtelefon bleibt es still. Erreichbar über meine Rufnummer bin ich auch nicht. Es scheint eine schwere Geburt zu werden.

VG

[Dr.Einstein]

Kann es vielleicht sein, dass die Namensauflösung über die 1. Leitung gemacht wird und dabei eine "falsche" IP Adresse zurückkommt, die gar nicht über die 2. VDSL Leitung erreichbar ist? Dein ganzes Zensieren macht das Helfen echt nicht einfach.

Gruß Dr.Einstein

[Tiffy]

Hi,

dass die Leitung nicht in den Status bereit wechselte, lag an der aktivierten Leitungsüberwachung. Wenn ich diese wieder aktiviere, bleibt der Status nicht bereit.

Ja, es könnte ein Problem mit der DNS-Konfiguration sein. Ein tr # vcm-dns liefert das Ergebnis, dass zum Outbound-Proxy keine IP-Adr. ermittelt werden kann. Ich habe heute diverse Konfigurationen getestet, leider bleibt dieser Fehler bestehen.

Ggf. hat jemand einen Konfigurationsvorschlag parat, den ich noch nicht getestet habe.

VG

[Tiffy]

Es bleibt mir ein Rätsel. Der Lancom kann für den SIP-PROXY keine IP-Adr. finden und ordnet bei VoIP vollkommen andere Adressen als die vorhandene Fritzbox zu. So bleibt mir nur übrig, mich von dem Gerät wieder zu trennen. Schade, auch wegen bislang positiver Erfahrungen mit den Lancom-Geräten.

[beki]

> Mit aktueller Firmware der FRITZ!Box lässt sich da recht wenig machen, weil Telnet da gesperrt ist.
Das größere Problem liegt darin, dass man die Konfig *nur* noch verschlüsselt aus dem Ding herausbekommt -- so meine Erfahrung als ich meine NetAachen VoIP Daten "hacken" musste.

> So bleibt mir nur übrig, mich von dem Gerät wieder zu trennen.
So ein Quatsch. Es ist okay wenn du aufgibst, aber das LANCOM kann mit der korrekten Konfiguration an deinem Anschluss betrieben werden, da habe ich keine Zweifel.

Hast du das korrekte Routing-Tag in der SIP-Line Konfiguration eingestellt? Ich vermute dem ist so weil du Pakete auf der zweiten VDSL Verbindung laufen siehst?

Welche Firmware nutzt du?

Warum trägst du nicht die Domain deines Providers als "Domain" ein und die Adresse, an die SIP Pakete geschickt werden sollen, als "Registrar"? Wie ich das verstanden habe kennst du die IP Adresse ja schon durch das Beobachten des Verhaltens der FritzBox.

Warum gehst du deinem Provider nicht so lange auf den Senkel bis er dir die technischen Hintergründe erläutert? Du musst wissen welcher DNS-Server dir die IP des Registrars auflösen kann, ob der nur über die zweite VDSL Verbindung erreichbar ist, welche IP-Adresse da herauskommen müsste, an welcher Domain du dich anmelden musst, wie dein Benutzername zusammengesetzt ist und was dein Passwort ist. Und dann wird es machbar sein das LANCOM korrekt einzurichten.

Alternativ wäre ein Mitschnitt des erstern REGISTER deiner FritzBox hilfreich. Undzwar unmaskiert, bitte. In dieser Nachricht stecken keine geheimen Informationen.