7960 + 1&1, keine ankommenden Anrufe

[mschatz]

Hallo an alle

Habe ein Problem mit meinem 7960. Betreibe das Telefon mit 1&1 sowie mit Sipgate. Bei Sipgate funktioniert alles super, rein- und raustelefonieren klappt gut.

Bei den Nummern bei 1&1, egal ob T-Com-Nummer oder geographische Nummer, ist es nicht möglich angerufen zu werden. Es kommt die Meldung: "Dü Dü Dü, Ihr Anruf kann zur Zeit nicht durchgestellt werden."

Finde ich irgendwie ein bissel komisch weil die Einstellungen bei Sipgate ja auch funktionieren. Ich hatte schonmal in irgend einem Thread aufgefangen, dass es da eventuell Probleme bei der Übermittlung der öffentlichen IP gibt. Was konkretes weiß ich da leider nicht.

Wäre schön wenn mir jemand helfen könnte.
Gruß M. Schatz



### INFOS ###
Cisco 7960G mit SIP FW-7.4
VoIP: 1&1, Sipgate
Inet: 1&1, Carrier ist DTAG

 

[RB]

Moin!

Wie Du schon schreibst, könnte das ein Problem mit der öffentlichen IP-Adresse sein.

Sipgate hat wohl einen recht ausgeklügelten Mechanismus, um zu erkennen, ob ein Client hinter einem NAT-Router steckt und welches die öffentliche IP-Adresse dieses Clients ist. Das funktioniert wohl auch dann, wenn bei der Registrierung des Clients die falsche IP-Adresse (also die interne, private) mitgeschickt wird.

GMX und 1&1 haben anscheinend keine solchen Mechanismen eingebaut. Bei vielen Clients kann man sich mittels STUN behelfen. Das kann das Cisco aber nicht!

Für Nicht-Sipgate-Konten ist es daher wichtig, daß bei den Cisco-Telefonen unter nat_address die externe (öffentliche) IP-Adresse des Telefons drinsteht.

Bei mir habe ich das dadurch gelöst, daß ich eine (Sub-)Domain bei dyndns.org registriert und diese mit nat_address="<MyDomain>.dyndns.org" eingetragen habe. Mein Router sorgt für's Update dieser DynDNS-Adresse bei Änderungen. Bei einer Registrierung holt sich das Telefon dann über die Namensauflösung die öffentliche IP-Adresse und schickt diese mit an den Provider.

Des weiteren hat das Cisco auch selber so seine "Tricks", um herauszukriegen, unter welcher IP-Adresse es aus dem Internet erreichbar ist. Das funktioniert wohl ähnlich wie bei Sipgate. Anscheinend extrahiert das Cisco aus den Antwortpaketen vom Provider die eigene IP-Adresse.

Für den Zweck muß man aber dann auch nat_enable und nat_received_processing einschalten.

 

[mschatz]

Danke für die Antwort.

Ein DDNS habe ich und der ist auch unter nat_address eingetragen. nat_enable und nat_received_processing stehen auch auf 1. Ist alles irgendwie nen bissel komisch.

Gruß,
M. Schatz

 

[RB]

Tja, wenn das nicht die Ursache war, ist das tatsächlich etwas schleierhaft. Mein nächster Schritt wäre, im Cisco mal Debugging einzuschalten und die fraglichen Phasen mitzuschreiben (das wäre hier ein kompletter Rgistriervorgang, sowie ein abgehender und ein ankommender Anruf).

Parallel dazu wäre ein Blick ins Log des Routers (so vorhanden) hilfreich, um ggf festzustellen, ob der irgendwelche Bauchschmerzen hat.

Ich kenne bei mir z.B. den Effekt, daß manche Provider die Signalisierung nicht auf dem Port machen, den man als voip_control_port eingetragen hat, und der demzufolge auch im REGISTER dem Provider kundgetan wird, sondern daß stattdessen einfach der Port benutzt wird, von dem das REGISTER empfangen wurde. Da das durch NAT normalerweise ein mehr oder weniger zufälliger Port ist, kriegt man dann ein Problem mit der Portweiterleitung.

 

[mschatz]

Was für Ports muss ich denn überhaupt forwarden wenn ich ein Cisco 7960 mit 1&1 betreiben möchte? Im moment habe ich voip_control_port=5061, bei den einzelnen lines jeweils port 5060 für den proxy_port und media_ports von 16384 bis 16388. Ist das richtig?

Was genau müsste ich denn machen wenn ich mich per Telnet auf dem Telefon anmelde und dann die passenden Meldungen sehen möchte? Also per Telnet auf das Telefon ist ja klar aber welche Debug Messages sind für mich wichtig?

Gruß,
M. Schatz

 

[RB]

Port Forwarding ist unabhängig vom Provider immer gleich - richtet sich also normalerweise nur nach dem Client.

Maßgeblich ist der voip_control_port und die media ports. Die müssen an das Telefon durchgereicht werden. Die Ports bei den einzelnen Proxies sind die Zielports beim Provider, brauchen also keine Weiterleitung.

Die beschriebenen Ports sind in erstmal Ordnung so. Natürlich nur, solange nicht irgendwo anders dadurch ein Konflikt entsteht (z.B. bei anderen Clients).

Zum Debugging sollte erstmal der Befehl "debug timestamp sip-messages" reichen. Zum Beenden dann "undebug all". Die Ausgabe erfolgt allerdings im Telnet-Fenster. Wenn man Putty benutzt, kann man das alles dann schön in eine Datei mitschreiben lassen.

 

[mschatz]

Moin!

So, habe jetzt mal mitgeloggt was das Telefon mir ausgibt wenn ich da anrufe. Es passiert auf jeden Fall etwas wenn ein Anruf kommt. Das Logfile liegt im Anhang. Vielleicht kann mir jemand sagen woran es liegt.

Gruß,
M. Schatz

 

[RB]

Ich schaue es mir mal an. Wahrscheinlich komme ich aber erst am Freitag dazu, genauer hinzuschauen. Was auf Anhieb auffällt, ist der "500 - Internal Server Error", der ein paar mal zu sehen ist.

Aber das muß man in Ruhe zerpfluecken...

 

[RB]

Moin!

Jetzt hatte ich endlich mal Zeit, mir das Log-File anzuschauen. Sogar noch vor Freitag (hatte ja nicht gesagt, welcher Freitag)

Also:
Der Anruf von 1&1(?) kommt an und hat eine öffentliche IP-Adresse als Ziel eingetragen. Diese Fehler-Ursache ist also wohl außen vor.

Das Telefon reagiert auf jedes INVITE mit SIP/2.0 500 Internal Server Error. Es lehnt also den Anruf ab mit der Begründung, daß es irgendeinen internen Fehler hat?! Diese Antwort schickt das Cisco aber an 492573578326, was merkwürdigerweise die angerufene Nummer im INVITE ist. Der Provider reagiert auch nicht auf den Fehlercode, sondern schickt munter weiter seine INVITEs. :shock:

Weiter fallen mir die ganzen VIA-Zeilen auf. Das sind ungewöhnlich viele. Auch das Diversion ist merkwürdig. Ich kann mir da erstmal keinen Reim drauf machen. Als ob da eine Rufumleitung aktiv wäre... Um da weiterzukommen müsste ich jetzt erstmal die RFCs studieren, was das alles genau bedeutet. Und da habe ich derzeit leider nicht dieselbe dazu.

Vielleicht könnten sich <Maik> <rajo> oder <koehler> das ganze mal ansehen. Die haben, glaube ich, intimere Kenntnisse des SI-Protokolls...

Aber eine Frage: Der Anruf - kam der auch von einer VoIP-Telefonnummer oder war das Festnetz? Sieht irgendwie nach VoIP aus, würde ich unbedarft meinen.

Für die interessierten hier jetzt mal die beiden aufeinanderfolgenden Telegramme, erst das INVITE, dann die Fehlermeldung 500 als Antwort. Diese Abfolge tritt mehrfach in der oben als Attachment angefügten Datei auf. Ab und zu kommt übrigens auch mal ein ACK vom Provider, was ihn aber nicht hindert, direkt wieder ein INVITE hinterherzuschicken. :?

INVITE vom Provider an das Cisco-Telefon

INVITE sip:492573578326@80.143.142.83:5061 SIP/2.0
Record-Route: <sip:212.227.15.225;ftag=804136616;lr=on>
Record-Route: <sip:[email protected];ftag=804136616;lr=on>
Via: SIP/2.0/UDP 212.227.15.197;branch=z9hG4bK55b85a6b5fe538a1d99ef6deb0ef0b1c
Via: SIP/2.0/UDP 212.227.15.225;branch=z9hG4bKfb13.1ce81396.0
Via: SIP/2.0/UDP 212.227.15.197;branch=z9hG4bKfca9004f3cbe4d744d84dc69fe789867
Via: SIP/2.0/UDP 217.188.44.231;branch=z9hG4bKfb13.d38f06e4.0
Via: SIP/2.0/UDP 1und1.sip.mgc.voip.telefonica.de:5060 ;received=195.71.9.100;branch=z9hG4bKterm-a8d829-+492519829080-+492573578326
From: +492519829080 <sip:[email protected];user=phone> ;tag=804136616
To: +492573578326 <sip:[email protected];user=phone>
Call-ID: [email protected]
CSeq: 1 INVITE
Supported: timer
Session-Expires: 300
Min-SE: 10
Contact: <sip:[email protected]:5060>
Allow: INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,UPDATE
Max-Forwards: 6
Content-Type: application/sdp
Content-Length: 619
Diversion: <sip:[email protected];user=phone>;reason=additional

v=0
o=- 197440 0 IN IP4 62.53.147.12
s=Cisco SDP 0
c=IN IP4 62.53.147.12
t=0 0
m=audio 17650 RTP/AVP 8 0 99 102 2 103 4 104 105 106 107 18 0 125 101 100
a=rtpmap:99 G726-16/8000
a=rtpmap:102 G726-24/8000
a=rtpmap:103 G7231-H/8000
a=rtpmap:104 G7231-L/8000
a=rtpmap:105 G729b/8000
a=rtpmap:106 G7231a-H/8000
a=rtpmap:107 G7231a-L/8000
a=rtpmap:125 GnX64/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194,200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 192-194,200-202
a=X-cap: 2 image udptl t38

Antwort vom Cisco-Telefon

SIP/2.0 500 Internal Server Error
Via: SIP/2.0/UDP 212.227.15.197;branch=z9hG4bK55b85a6b5fe538a1d99ef6deb0ef0b1c,SIP/2.0/UDP 212.227.15.225;branch=z9hG4bKfb13.1ce81396.0,SIP/2.0/UDP 212.227.15.197;branch=z9hG4bKfca9004f3cbe4d744d84dc69fe789867,SIP/2.0/UDP 217.188.44.231;branch=z9hG4bKfb13.d38f06e4.0,SIP/2.0/UDP 1und1.sip.mgc.voip.telefonica.de:5060 ;received=195.71.9.100;branch=z9hG4bKterm-a8d829-+492519829080-+492573578326
From: +492519829080 <sip:[email protected];user=phone> ;tag=804136616
To: +492573578326 <sip:[email protected];user=phone>
Call-ID: [email protected]
Date: Wed, 14 Sep 2005 14:06:03 GMT
CSeq: 1 INVITE
Content-Length: 0