Cisco IP Phone 7975 einrichten, wer kann helfen? (zum 2.)
Wer kann mir helfen ein Cisco 7975 zügig einzurichten damit es läuft? Die Firmware wäre SIP, einige Tastenbelegungen, SIP Provider, Ports usw...sollten eingestellt werden, zudem auch mehr Klingeltöne ev. zusätzliche Hintergrundbilder (letzteres wäre nicht so dringend).. TFTP Server ist vorhanden. Das Telefon ist noch vom Vorgänger eingerichtet, dieser hatte es via Fritzbox betrieben, ich werde es direkt betreiben, wie ich auch meine Aastra Apparate eingerichtet habe (diese konnte man bequem via Weboberfläche einrichten)..
Sonst via PM...
Danke!
Sonst via PM...
Danke!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 240478
Url: https://administrator.de/contentid/240478
Ausgedruckt am: 22.11.2024 um 04:11 Uhr
20 Kommentare
Neuester Kommentar
Bevor wir ins Eingemachte gehen...
Wichtig ist die Datei SEP<MacAdrTel>.cnf.xml in der sind alle deine Konfig Parameter enthalten die du für den Betrieb benötigst. Diese muss nach Änderung immer neu geladen werden.
Da das Telefon schonmal mit einer FB zusammengearbeitet hat kann man (geraten) davon ausgehen das es schon ein SIP Image drauf hat ?!
Du solltest es aber besser nackig machen von irgendwelchen Konfigs.
Die Factory Reset Prozedur ist: das Telefon vom Strom trennen, dann die "#" Taste gedrückt halten und Telefon mit dem Netzteil verbinden.
"#" solange gedrückt halten bis die Tasten rechts vom Display als "Lauflicht" erscheinen.
Dann # Taste loslassen und 123456789*0# eingeben.
Das Telefon löscht dann alle Einstellungen.
Es gibt auch den ganz harten Reset mit der Kombination 3491672850*# was aber das komplette Flash des Telefons löscht. Damit lädst du dann nur den nackten Bootloader.
Letzteres erzwingt aber einen Konsolport, da auch dann das Display leer bleibt.
Neben dem Ethernet LAN Port ist eine RJ-11 Buchse mit der Bezeichnung (AUX) Dort liegt ein Terminal Anschluss mit 9600 Baud drauf den du mit einem Terminal Programm wie TeraTerm oder PuTTy benutzen kannst und sehen kannst was das Telefon macht quasi wie auf einem Bildschirm.
Das ist generell sehr hilfreich auch für das Setup des Telefons.
Die Pin Belegung der RJ-11 Buchse von einem RJ-11 auf RJ-45 Kabel ist:
RJ-11, Pin 2 --> RJ-45, Pin 6
RJ-11, Pin 3 --> RJ-45, Pin 4
RJ-11, Pin 4 --> RJ-45, Pin 3
Du kannst ein ganz normales RJ-11 zu RJ-11 Kabel nehmen und das entsprechend umlöten oder ein RJ-11 auf RJ-45 Kabel. Gibts für wenig Geld in jedem PC- oder Telefonshop.
Man kann dann den ganz normalen Terminal Adapter RJ-45 auf DB-9 z.B. von Cisco nehmen und dann mit einem Standard USB zu Seriell Adapter arbeiten sofern man keinen seriellen COM Port mehr am Rechner hat.
Wie gesagt...wichtig ist nachher die .cnf.xml Konfig Datei. Da die Telefon primär für einen Cisco Call Manager Betrieb gedacht sind ist die Konfig etwas tricky, funktioniert aber fehlerlos.
Im Mitbewerber Forum IP Phone Forum findest du weitere hilfreiche Infos dazu !
Oder direkt hier:
Cisco Telefone für All IP Anschluss, FritzBox und andere VoIP Anlagen fit machen
- Aktuelles SIP Image cmterm-7975-sip.9-3-1SR4-1.zip hast du per TFTP installiert auf dem Telefon ? (Achtung: solltest du eine ältere Version als 8.5.2 haben musst du zuerst auf 8.5.3 updaten und dann auf 9.3.1 ! Ein direktes Update von älteren Versionen auf 9.3 ist nicht supportet)
- SEP<MacAdrTel>.cnf.xml hast du erstellt mit deinen Daten ?
Wichtig ist die Datei SEP<MacAdrTel>.cnf.xml in der sind alle deine Konfig Parameter enthalten die du für den Betrieb benötigst. Diese muss nach Änderung immer neu geladen werden.
Da das Telefon schonmal mit einer FB zusammengearbeitet hat kann man (geraten) davon ausgehen das es schon ein SIP Image drauf hat ?!
Du solltest es aber besser nackig machen von irgendwelchen Konfigs.
Die Factory Reset Prozedur ist: das Telefon vom Strom trennen, dann die "#" Taste gedrückt halten und Telefon mit dem Netzteil verbinden.
"#" solange gedrückt halten bis die Tasten rechts vom Display als "Lauflicht" erscheinen.
Dann # Taste loslassen und 123456789*0# eingeben.
Das Telefon löscht dann alle Einstellungen.
Es gibt auch den ganz harten Reset mit der Kombination 3491672850*# was aber das komplette Flash des Telefons löscht. Damit lädst du dann nur den nackten Bootloader.
Letzteres erzwingt aber einen Konsolport, da auch dann das Display leer bleibt.
Neben dem Ethernet LAN Port ist eine RJ-11 Buchse mit der Bezeichnung (AUX) Dort liegt ein Terminal Anschluss mit 9600 Baud drauf den du mit einem Terminal Programm wie TeraTerm oder PuTTy benutzen kannst und sehen kannst was das Telefon macht quasi wie auf einem Bildschirm.
Das ist generell sehr hilfreich auch für das Setup des Telefons.
Die Pin Belegung der RJ-11 Buchse von einem RJ-11 auf RJ-45 Kabel ist:
RJ-11, Pin 2 --> RJ-45, Pin 6
RJ-11, Pin 3 --> RJ-45, Pin 4
RJ-11, Pin 4 --> RJ-45, Pin 3
Du kannst ein ganz normales RJ-11 zu RJ-11 Kabel nehmen und das entsprechend umlöten oder ein RJ-11 auf RJ-45 Kabel. Gibts für wenig Geld in jedem PC- oder Telefonshop.
Man kann dann den ganz normalen Terminal Adapter RJ-45 auf DB-9 z.B. von Cisco nehmen und dann mit einem Standard USB zu Seriell Adapter arbeiten sofern man keinen seriellen COM Port mehr am Rechner hat.
Wie gesagt...wichtig ist nachher die .cnf.xml Konfig Datei. Da die Telefon primär für einen Cisco Call Manager Betrieb gedacht sind ist die Konfig etwas tricky, funktioniert aber fehlerlos.
Im Mitbewerber Forum IP Phone Forum findest du weitere hilfreiche Infos dazu !
Oder direkt hier:
Cisco Telefone für All IP Anschluss, FritzBox und andere VoIP Anlagen fit machen
Bitte lasse den Unsinn mit externen Bilderlinks. Wie du beim Erstellen des Threads gesehen hast gibt es hier im Forum eine Bilder Upload Funktion ! Klicke auf "Bearbeiten" in deinem Originalthread dann kannst du den Buttom oben nicht übersehen.
Nach dem Hochladen der Bilder kannst du den Bilder "URL" mit einem Rechtsklick und cut and paste in jeglichen Text hier bringen ! Auch Antworten !! Statt des Image URLs wird immer dein Bild angezeigt !
Kann man auch immer noch nachträglich machen.
Zurück zu deinen Fragen...:
Dafür das es nicht lädt gibt es 2 Gründe:
1.) Du bist zu ungeduldig. Das komplette Laden mit TFTP32 dauert bis zu 20min, da er zwischendurch einen Reset ausführt. Mit einem Konsolkabel kannst du das verfolgen.
Also lass ihn mal ne Viertelstunde rumrödeln... wenn du auf den TFTP Status siehst die ganze Zeit zeigt er auch an das er den File lädt.
WICHTIG: Das <loadInformation>SIP75.8-3-2SR1S</loadInformation> in der Konfig MUSS mit dem SIPxyz....loads File auf deinem TFTP Server übereinstimmen !!
2.) Du hast einen Syntax Error im XML File. Fehlt dort nur ein ">" oder ist ein Leerzeichen zuviel bricht er ab.
Einen kann man gleich schon oven an der NTP Konfig sehen bei dir:
<timeZone>Pacific Standard/Daylight Time</timeZone>
<ntps>
<ntp>
<name>{TBexternalIPaddress}</name>
<ntpMode>Unicast</ntpMode>
</ntp>
Daran scheitert er schonmal... Weil du vergessen hast die Platzhalter dort in echte IP Adressen oder deine User bezogenen Settings abzuändern !!!
Kontrolliere daraufhin nochmal die komplette Syntax !
So sähe z.B eine syntaktisch richtige Uhrzeit Einstellung für Europa aus:
Wenn du das entsprechend in deiner SEP Settings XML Datei abänderst und die gebootet ist per TFTP siehst du es sofort im Display. Ist dann auch ein Indiz für dich das er deine SEP....cnf.xml Datei richtig lädt !!
Das Telefon sollte aber immer bis zum Status "Registering" im Display kommen.
Wenn es da hängen bleibt ist alles drin nur das Anmelden am SIP Server schlägt dann fehl.
Hier hilft es mal mit dem Wireshark nachzusehen ob das Telefon wirklich mit dem richtigen SIP Account daherkommt.
Nach dem Hochladen der Bilder kannst du den Bilder "URL" mit einem Rechtsklick und cut and paste in jeglichen Text hier bringen ! Auch Antworten !! Statt des Image URLs wird immer dein Bild angezeigt !
Kann man auch immer noch nachträglich machen.
Zurück zu deinen Fragen...:
dennoch lädt das Telefon das file nicht rein, wenn ich nun einen Fabrikreset durchführe, sollte er es dann ziehen?
Ja, nach einem normalen Factory Reset mit 1234567... lädt er die .cnf.xml Datei immer neu.Dafür das es nicht lädt gibt es 2 Gründe:
1.) Du bist zu ungeduldig. Das komplette Laden mit TFTP32 dauert bis zu 20min, da er zwischendurch einen Reset ausführt. Mit einem Konsolkabel kannst du das verfolgen.
Also lass ihn mal ne Viertelstunde rumrödeln... wenn du auf den TFTP Status siehst die ganze Zeit zeigt er auch an das er den File lädt.
WICHTIG: Das <loadInformation>SIP75.8-3-2SR1S</loadInformation> in der Konfig MUSS mit dem SIPxyz....loads File auf deinem TFTP Server übereinstimmen !!
2.) Du hast einen Syntax Error im XML File. Fehlt dort nur ein ">" oder ist ein Leerzeichen zuviel bricht er ab.
Einen kann man gleich schon oven an der NTP Konfig sehen bei dir:
<timeZone>Pacific Standard/Daylight Time</timeZone>
<ntps>
<ntp>
<name>{TBexternalIPaddress}</name>
<ntpMode>Unicast</ntpMode>
</ntp>
Daran scheitert er schonmal... Weil du vergessen hast die Platzhalter dort in echte IP Adressen oder deine User bezogenen Settings abzuändern !!!
Kontrolliere daraufhin nochmal die komplette Syntax !
So sähe z.B eine syntaktisch richtige Uhrzeit Einstellung für Europa aus:
<dateTimeSetting>
<dateTemplate>D.M.YY</dateTemplate>
<timeZone>Central Europe Standard/Daylight Time</timeZone>
<ntps>
<ntp>
<name>130.149.17.21</name>
<ntpMode>Unicast</ntpMode>
</ntp>
</ntps>
</dateTimeSetting>
Das Telefon sollte aber immer bis zum Status "Registering" im Display kommen.
Wenn es da hängen bleibt ist alles drin nur das Anmelden am SIP Server schlägt dann fehl.
Hier hilft es mal mit dem Wireshark nachzusehen ob das Telefon wirklich mit dem richtigen SIP Account daherkommt.
Eine gute Anlaufstelle ist auch:
http://wiki.ip-phone-forum.de/telefone:cisco:start
Dort findest du ebenfalls eine lauffähige XML Datei.
http://wiki.ip-phone-forum.de/telefone:cisco:start
Dort findest du ebenfalls eine lauffähige XML Datei.
Hier meine Config für das Cisco IP Phone 7975 in Verbindung mit Sipgate.
Mein Cisco hat eine eine deutsche locale Info und die aktuellste SIP Firmware SIP75.9-3-1SR4-1S.
Firewall/NAT entsprechend konfiguriert, registriert sich mein Cisco bei Sipgate und Anrufe nach draußen sind möglich.
Einziges nicht lösbares Problem in Verbindung mit Sipgate sind ankommende Anrufe.
Dies liegt wohl leider am Cisco, denn bei der Registrierung löst das Cisco den FQDN warum auch immer einfach auf die entsprechende IP auf, was seitens Sipgate nicht unterstützt wird (Sipgate Support). Registrierung und Anrufe nach draußen sind dann zwar möglich, aber es werden keine Anrufe durchgestellt.
In Wireshark sieht mann dann:
Session Initiation Protocol (REGISTER)
Request-Line: REGISTER sip:217.10.79.9 SIP/2.0
Also
REGISTER sip:217.10.79.9 SIP/2.0
anstatt
REGISTER sip:sipgate.de SIP/2.0
Warum der Cisco das macht, weiß bestimmt nur Cisco.
Ich habe bisher keine Möglichkeit gefunden, das abzustellen.
Neben dieser Merkwürdigkeit ist auch das "Problem", dass das Cisco Phone SIP Requests nicht von dem Port 5060 sendet, sondern vom 40.0000 und 50.000er Bereich, aber antworten auf Port 5060 erwartet.
Hier nun meine Config:
Meine Dialplan.xml habe ich noch nicht wirklich angepasst.
Hier noch mein Dateien für das Cisco Phone auf meinem TFTP:
Mein Cisco hat eine eine deutsche locale Info und die aktuellste SIP Firmware SIP75.9-3-1SR4-1S.
Firewall/NAT entsprechend konfiguriert, registriert sich mein Cisco bei Sipgate und Anrufe nach draußen sind möglich.
Einziges nicht lösbares Problem in Verbindung mit Sipgate sind ankommende Anrufe.
Dies liegt wohl leider am Cisco, denn bei der Registrierung löst das Cisco den FQDN warum auch immer einfach auf die entsprechende IP auf, was seitens Sipgate nicht unterstützt wird (Sipgate Support). Registrierung und Anrufe nach draußen sind dann zwar möglich, aber es werden keine Anrufe durchgestellt.
In Wireshark sieht mann dann:
Session Initiation Protocol (REGISTER)
Request-Line: REGISTER sip:217.10.79.9 SIP/2.0
Also
REGISTER sip:217.10.79.9 SIP/2.0
anstatt
REGISTER sip:sipgate.de SIP/2.0
Warum der Cisco das macht, weiß bestimmt nur Cisco.
Ich habe bisher keine Möglichkeit gefunden, das abzustellen.
Neben dieser Merkwürdigkeit ist auch das "Problem", dass das Cisco Phone SIP Requests nicht von dem Port 5060 sendet, sondern vom 40.0000 und 50.000er Bereich, aber antworten auf Port 5060 erwartet.
Hier nun meine Config:
<device>
<deviceProtocol>SIP</deviceProtocol>
<sshUserId>admin</sshUserId>
<sshPassword>meinpasswort</sshPassword>
<devicePool>
<dateTimeSetting>
<dateTemplate>D.M.Y</dateTemplate>
<timeZone>W. Europe Standard/Daylight Time</timeZone>
<ntps>
<ntp>
<name>irgendein_ntp_server</name>
<ntpMode>Unicast</ntpMode>
</ntp>
</ntps>
</dateTimeSetting>
<callManagerGroup>
<tftpDefault>true</tftpDefault>
<members>
<member priority="0">
<callManager>
<ports>
<ethernetPhonePort>2000</ethernetPhonePort>
<sipPort>5060</sipPort>
<securedSipPort>5061</securedSipPort>
</ports>
<processNodeName>sipgate.de</processNodeName>
</callManager>
</member>
</members>
</callManagerGroup>
</devicePool>
<sipProfile>
<sipProxies>
<backupProxy></backupProxy>
<backupProxyPort></backupProxyPort>
<emergencyProxy></emergencyProxy>
<emergencyProxyPort></emergencyProxyPort>
<outboundProxy>sipgate.de</outboundProxy>
<outboundProxyPort>5060</outboundProxyPort>
<registerWithProxy>true</registerWithProxy>
</sipProxies>
<sipCallFeatures>
<cnfJoinEnabled>true</cnfJoinEnabled>
<callForwardURI>x--serviceuri-cfwdall</callForwardURI>
<callPickupURI>x-cisco-serviceuri-pickup</callPickupURI>
<callPickupListURI>x-cisco-serviceuri-opickup</callPickupListURI>
<callPickupGroupURI>x-cisco-serviceuri-gpickup</callPickupGroupURI>
<meetMeServiceURI>x-cisco-serviceuri-meetme</meetMeServiceURI>
<abbreviatedDialURI>x-cisco-serviceuri-abbrdial</abbreviatedDialURI>
<rfc2543Hold>false</rfc2543Hold>
<callHoldRingback>2</callHoldRingback>
<localCfwdEnable>true</localCfwdEnable>
<semiAttendedTransfer>true</semiAttendedTransfer>
<anonymousCallBlock>2</anonymousCallBlock>
<callerIdBlocking>2</callerIdBlocking>
<dndControl>0</dndControl>
<remoteCcEnable>true</remoteCcEnable>
</sipCallFeatures>
<sipStack>
<sipInviteRetx>6</sipInviteRetx>
<sipRetx>10</sipRetx>
<timerInviteExpires>180</timerInviteExpires>
<timerRegisterExpires>600</timerRegisterExpires>
<timerRegisterDelta>5</timerRegisterDelta>
<timerKeepAliveExpires>120</timerKeepAliveExpires>
<timerSubscribeExpires>120</timerSubscribeExpires>
<timerSubscribeDelta>5</timerSubscribeDelta>
<timerT1>500</timerT1>
<timerT2>4000</timerT2>
<maxRedirects>70</maxRedirects>
<remotePartyID>false</remotePartyID>
<userInfo>None</userInfo>
</sipStack>
<autoAnswerTimer>1</autoAnswerTimer>
<autoAnswerAltBehavior>false</autoAnswerAltBehavior>
<autoAnswerOverride>true</autoAnswerOverride>
<transferOnhookEnabled>false</transferOnhookEnabled>
<enableVad>false</enableVad>
<preferredCodec>none</preferredCodec>
<dtmfAvtPayload>101</dtmfAvtPayload>
<dtmfDbLevel>3</dtmfDbLevel>
<dtmfOutofBand>avt</dtmfOutofBand>
<alwaysUsePrimeLine>false</alwaysUsePrimeLine>
<alwaysUsePrimeLineVoiceMail>false</alwaysUsePrimeLineVoiceMail>
<kpml>3</kpml>
<natEnabled>true</natEnabled>
<natAddress>meinfunktionsfähiger_DynDNS_Dienst</natAddress>
<phoneLabel>Name_weniger_als_12_Zeichen</phoneLabel>
<stutterMsgWaiting>1</stutterMsgWaiting>
<callStats>false</callStats>
<silentPeriodBetweenCallWaitingBursts>10</silentPeriodBetweenCallWaitingBursts>
<disableLocalSpeedDialConfig>false</disableLocalSpeedDialConfig>
<startMediaPort>16384</startMediaPort>
<stopMediaPort>16390</stopMediaPort>
<sipLines>
<line button="1">
<featureID>9</featureID>
<featureLabel>Sipgate</featureLabel>
<proxy>USECALLMANAGER</proxy>
<port>5060</port>
<name>1234567(SIPGATE-ID_ohne_den_KLammerteil)</name>
<displayName>Mein_Nachname</displayName>
<autoAnswer>
<autoAnswerEnabled>2</autoAnswerEnabled>
</autoAnswer>
<callWaiting>3</callWaiting>
<authName>1234567(SIPGATE-ID_ohne_den_KLammerteil)</authName>
<authPassword>mein_Sipgatepasswort</authPassword>
<sharedLine>false</sharedLine>
<messageWaitingLampPolicy>1</messageWaitingLampPolicy>
<messagesNumber>50000</messagesNumber>
<ringSettingIdle>4</ringSettingIdle>
<ringSettingActive>5</ringSettingActive>
<contact>1234567(SIPGATE-ID_ohne_den_KLammerteil)</contact>
<forwardCallInfoDisplay>
<callerName>true</callerName>
<callerNumber>false</callerNumber>
<redirectedNumber>false</redirectedNumber>
<dialedNumber>true</dialedNumber>
</forwardCallInfoDisplay>
</line>
</sipLines>
<voipControlPort>5060</voipControlPort>
<dscpForAudio>184</dscpForAudio>
<ringSettingBusyStationPolicy>0</ringSettingBusyStationPolicy>
<dialTemplate>dialplan.xml</dialTemplate>
</sipProfile>
<commonProfile>
<phonePassword></phonePassword>
<backgroundImageAccess>true</backgroundImageAccess>
<callLogBlfEnabled>0</callLogBlfEnabled>
</commonProfile>
<loadInformation>SIP75.9-3-1SR4-1S</loadInformation>
<vendorConfig>
<disableSpeaker>false</disableSpeaker>
<disableSpeakerAndHeadset>false</disableSpeakerAndHeadset>
<pcPort>1</pcPort>
<settingsAccess>1</settingsAccess>
<garp>0</garp>
<voiceVlanAccess>0</voiceVlanAccess>
<videoCapability>0</videoCapability>
<autoSelectLineEnable>0</autoSelectLineEnable>
<webAccess>0</webAccess>
<spanToPCPort>1</spanToPCPort>
<loggingDisplay>1</loggingDisplay>
<loadServer></loadServer>
<daysDisplayNotActive>1,2,3,4,5,6,7</daysDisplayNotActive>
<displayOnTime></displayOnTime>
<displayOnDuration></displayOnDuration>
<displayIdleTimeout>00:02</displayIdleTimeout>
<displayOnWhenIncomingCall>1</displayOnWhenIncomingCall>
</vendorConfig>
<versionStamp>1143565489-a3cbf294-7526-4c29-8791-c4fce4ce4c37</versionStamp>
<userLocale>
<name>German_Germany</name>
<uid>1</uid>
<langCode>de_DE</langCode>
<version></version>
<winCharSet>iso-8859-1</winCharSet>
</userLocale>
<networkLocale>Germany</networkLocale>
<networkLocaleInfo>
<name>Germany</name>
<version></version>
</networkLocaleInfo>
<deviceSecurityMode>1</deviceSecurityMode>
<authenticationURL></authenticationURL>
<directoryURL></directoryURL>
<idleTimeout>0</idleTimeout>
<idleURL></idleURL>
<informationURL></informationURL>
<messagesURL></messagesURL>
<proxyServerURL></proxyServerURL>
<servicesURL></servicesURL>
<dscpForSCCPPhoneConfig>96</dscpForSCCPPhoneConfig>
<dscpForSCCPPhoneServices>0</dscpForSCCPPhoneServices>
<dscpForCm2Dvce>96</dscpForCm2Dvce>
<transportLayerProtocol>2</transportLayerProtocol>
<capfAuthMode>0</capfAuthMode>
<capfList>
<capf>
<phonePort>3804</phonePort>
</capf>
</capfList>
<certHash></certHash>
<encrConfig>false</encrConfig>
</device>
Meine Dialplan.xml habe ich noch nicht wirklich angepasst.
<DIALTEMPLATE>
<TEMPLATE MATCH="*" Timeout="5" />
</DIALTEMPLATE>
Hier noch mein Dateien für das Cisco Phone auf meinem TFTP:
German_Germany
td-sip.jar
Germany
g3-tones.xml
apps75.9-3-1ES26.sbn
cnu75.9-3-1ES26.sbn
cvm75sip.9-3-1ES26.sbn
dialplan.xml
dsp75.9-3-1ES26.sbn
jar75sip.9-3-1ES26.sbn
SEP_MACAdresse_.cnf.xml
SIP75.9-3-1SR4-1S.loads
term75.default.loads
Wireshark ersetzt dir den FQDN Namen mit der IP, das macht nicht das Telefon.
Was das Telefon als User Registering sendet findest du immer im Content des Pakets nicht aber im Header. Das ersetzten des FQDNs kannst du in den Wireshark Settings auch abschalten.
Das incoming Calls nicht funktionieren hat was mit deinem NAT zu tun ! Vermutlich hast du kein Port Forwarding auf dem NAT Router oder was auch immer eingerichtet.
Die 796x Modelle funktionieren wenigstens wunderbar mit Sipgate (getestet). Dazu gibt es im Internet auch diverse Anleitungen.
Eigentlich sollte es mit den 797x Modellen dann auch klappen, denn vom Verhalten sind die identisch ?!
Der SIP Destination Port ist auch immer 5060 vom Telefon...muss ja auch so sein sonst würde ein SIP Server gar nicht reagieren wenns ein anderer Port wie 40.000 wäre. Der Source Port ist Random...da kann es sein das das 40 oder 50k ist. Kann das sein das du das verwechselt hast ?
Bau dir mal ein serielles Terminal Kabel für den AUX Port des Telefons und schliess das an PuTTY oder TeraTerm an, da kannst du dann ganz genau nachsehen was am Telefon passiert.
P.S.: Wo findet man die German tar Dateien und die Tones Datei ??
Was das Telefon als User Registering sendet findest du immer im Content des Pakets nicht aber im Header. Das ersetzten des FQDNs kannst du in den Wireshark Settings auch abschalten.
Das incoming Calls nicht funktionieren hat was mit deinem NAT zu tun ! Vermutlich hast du kein Port Forwarding auf dem NAT Router oder was auch immer eingerichtet.
Die 796x Modelle funktionieren wenigstens wunderbar mit Sipgate (getestet). Dazu gibt es im Internet auch diverse Anleitungen.
Eigentlich sollte es mit den 797x Modellen dann auch klappen, denn vom Verhalten sind die identisch ?!
Der SIP Destination Port ist auch immer 5060 vom Telefon...muss ja auch so sein sonst würde ein SIP Server gar nicht reagieren wenns ein anderer Port wie 40.000 wäre. Der Source Port ist Random...da kann es sein das das 40 oder 50k ist. Kann das sein das du das verwechselt hast ?
Bau dir mal ein serielles Terminal Kabel für den AUX Port des Telefons und schliess das an PuTTY oder TeraTerm an, da kannst du dann ganz genau nachsehen was am Telefon passiert.
P.S.: Wo findet man die German tar Dateien und die Tones Datei ??
Wireshark ersetzt dir den FQDN Namen mit der IP, das macht nicht das Telefon.
Was das Telefon als User Registering sendet findest du immer im Content des Pakets nicht aber im Header. Das ersetzten des FQDNs kannst du in den Wireshark Settings auch abschalten.
Nope.Was das Telefon als User Registering sendet findest du immer im Content des Pakets nicht aber im Header. Das ersetzten des FQDNs kannst du in den Wireshark Settings auch abschalten.
Ich habe die Pakete am WAN Interface meines Routers mit Portmirroring analysiert und konnte das von mir beschriebenes Verhalten beobachten.
Zum Vergleich habe ich den Registrierungsvorgang von einem Linksys SPA 2102 mit geschnitten.
Hier wird im Request sipgate.de verwendet.
Also:
REGISTER sip:sipgate.de SIP/2.0
Das incoming Calls nicht funktionieren hat was mit deinem NAT zu tun ! Vermutlich hast du kein Port Forwarding auf dem NAT Router oder was auch immer eingerichtet.
Leider auch nope.Es kommen am WAN Port ja erst gar keine Pakete bei einem Anruf an.
Ich bin das mit dem Sipgate Support auch durchgegangen und das Ergebnis war, dass wenn sich ein SIP Gerät mit der IP anstatt mit dem FQDN im SIP Paket registrieren will, dies von Sipgate nicht unterstützt wird.
Zitat: Sipgate Support:
Die Registrierung via IP führt zum beschriebenen Verhalten das Rückantworten nicht korrekt erfolgen können.
Technisch können wir die Registrierung an eine IP noch nicht unterbinden, würden dies aber wohl demnächst umsetzen, das Register Anfragen mit IP gleich abgewiesen werden.
Wie Sie das beim Cisco lösen können, wissen wir leider nicht. Verschiedene Cisco Geräte verhalten sich einfach nicht SIP Konform.
Wenn Sie es nachstellen wollen, können Sie beim Linksys die IP Adresse einstellen und hätten den gleichen Effekt.
Und ja, ich habe das mit dem Linksys nachgestellt und hier in der Config direkt die IP anstatt sipgate.de eingetragen und konnte das Problem so mit einem anderen Gerät nachstellen.Die Registrierung via IP führt zum beschriebenen Verhalten das Rückantworten nicht korrekt erfolgen können.
Technisch können wir die Registrierung an eine IP noch nicht unterbinden, würden dies aber wohl demnächst umsetzen, das Register Anfragen mit IP gleich abgewiesen werden.
Wie Sie das beim Cisco lösen können, wissen wir leider nicht. Verschiedene Cisco Geräte verhalten sich einfach nicht SIP Konform.
Wenn Sie es nachstellen wollen, können Sie beim Linksys die IP Adresse einstellen und hätten den gleichen Effekt.
Die 796x Modelle funktionieren wenigstens wunderbar mit Sipgate (getestet). Dazu gibt es im Internet auch diverse Anleitungen.
Ja, über die bin ich bei meiner Odyssee die letzten Wochen auch dauernd gestolpert, aber beim 7975 mit Sipgate siehts sehr mau aus.Die meisten nutzen es an einer Fritzbox oder Asterisk System und nicht direkt mit einem externen PBX.
Eigentlich sollte es mit den 797x Modellen dann auch klappen, denn vom Verhalten sind die identisch ?!
Ich glaub zwischen den 797x und den 796x Modellen ist dann wohl doch irgendwie ein Unterscheid bei der SIP Implementierung.Der SIP Destination Port ist auch immer 5060 vom Telefon...muss ja auch so sein sonst würde ein SIP Server gar nicht reagieren wenns ein anderer Port wie 40.000 wäre. Der Source Port ist Random...da kann es sein das das 40 oder 50k ist. Kann das sein das du das verwechselt hast ?
Nein, aber vielleicht nicht sehr gut formuliert.Ich meinte mit "von dem Port 5060 sendet" natürlich den Source Port, der beim Cisco high random ist.
Bau dir mal ein serielles Terminal Kabel für den AUX Port des Telefons und schliess das an PuTTY oder TeraTerm an, da kannst du dann ganz genau nachsehen was am Telefon passiert.
MH, damit hab ich ehrlich gesagt noch gar keine Erfahrung.Muss ich mir auf der Arbeit wohl mal ein Kabel nachbauen.
P.S.: Wo findet man die German tar Dateien und die Tones Datei ??
Die 2 benötigten Dateien hab ich aus "CME-locale-de_DE-German-9.5.2.6.tar".Hatte ich im Netz unter "cme-full-9-5-locale" gefunden.
Ich weiss aber nicht, ob das wirklich auch die aktuellsten sind.
Menü ist deutsch und die Töne bis auf das Freizeichen auch.
Danke für deine Antwort.
Für weitere Tipps bin ich immer offen.
Ich würde das Cisco schon gerne direkt mit Sipgate betreiben, denn das Telefon ist ansonsten ein sehr schönes Gerät.
Hier wird im Request sipgate.de verwendet.
Mmmhhh, müsste man mal checken ob man ggf. die Verwendung der ASCII Zeichen mit Hochkommas oder Anführungsstrichen in der Syntax erzwingen kann.Merkwürdig ist nur das es scheinbar mit 796x Modellen fehlerfrei rennt ?!
Es kommen am WAN Port ja erst gar keine Pakete bei einem Anruf an.
Oha, das zeigt aber eher dann ein graviuerendes Problem des Providers ?! Wenn dort ein eingehender Call reinkommt muss von dem auch ein SIP Request eingehen.Gut, wenn die Registrierung beim Provider natürlich durch falsche Userdaten (s.o.) unvollständig ist oder fehlerhaft ist, ist das natürlich was anderes.
Das Reproduzieren mit dem Linksys Telefon spricht da ja eine eindeutige Sprache und macht das eindeutig.
Wie gesagt...ggf. hilft das setzen in Hochkommas oder anderen Zeichen um die FQDN Umwandlung zu verhindern. Das ist ja dann kein Fehlverhalten des SIP an sich sondern das Handling mit Domain Namen und deren DNS Auflösung im Telefon selber.
Wenn du dir hier:
http://www.ip-phone-forum.de/showthread.php?t=67130&s=0a583f2e12e7a ...
mal ältere Konfig Files der 7960er ansiehst kannst du genau sehen das die die Usernamen mit FQDNs in Anführungszeichen gesetzt haben. Einen Versuch bei dir wärs wert.
Denk dran das du das Telefon dazu wieder resetten musst um die XML Datei zu laden beim Booten.
Normal sollte man erwarten das Usernamen nicht irgendwie aufgelöst werden also niemals manipuliert werden. Zu vermuten ist das das Telefon OS vermutlich immer wenn es FQDN Strings sieht diese aufzulösen ?!
MH, damit hab ich ehrlich gesagt noch gar keine Erfahrung.
Na ja "Erfahrung" muss man auch dafür nicht haben.Das ist ein Kinderspiel.... Für ein paar Cent ein RJ-11 Kabel kaufen und auf einer Seite einen DB-9 Stecker montieren. Wenn du noch einen seriellen COM Port hast im Rechner kannst du den dann direkt verwenden ansonsten für ein paar Euro einen USB - Seriell Adapter beschaffen.
Dann ein klassisches Terminalprogramm wie PuTTY oder TeraTerm installieren...et voila schon kann man sehen was das telefon so spricht.
Den genauen Anschlussplan findest du hier:
http://www.ip-phone-forum.de/showthread.php?t=90646
Ist ne Sache von 5 Minuten, dann rennt das.
Also das mit den Hochkommas oder Anführungszeichen war nicht erfolgreich.
Wenn ich damit experimentiere, sendet Das Cisco SIP Requests an die IP des TFTP (mein PC). Muss ich jetzt auch nicht verstehen...
Der Aufbau der 796x Configdateien ist ja generell auch ein völlig anderer, während die 797xer ja die typische "XML Syntax" vorschreiben.
Ich glaube, dass man dadurch mit Anführungszeichen und Co nicht weiterkommt.
Der Sipgate Support hat ja selbst gesagt, wenn im URI Request die IP statt sipgate.de verwendet wird, dass das von denen nicht unterstützt wird.
Mach ich immer, wenn ich an der Config rumspiele.
Einfach im Menü des Cisco die Einstellungen mit **# aktivieren und dann in den Netzwerksettings-IPv4-"Alternativ. TFTP Server" (Menüpunkt 16) de-/aktivieren.
Danach wird die Config erneut vom TFTP geladen und eingelesen.
Änderungen der Config sind dann sofort aktiv und das Gerät versucht sich erneut am PBX zu registrieren.
Zu dieser FQDN -> IP Umwandlung hab ich nur folgendes zum Beispiel gefunden.
http://www.cisco.com/c/en/us/td/docs/routers/asr1000/configuration/guid ...
Hier geht es genau um diese Thematik.
Aber nur in Verbindung mit Netzwerkgeräte von Cisco, die die URI-Requests manipulieren können.
So langsam glaub ich wirklich, dass das alles Teil des CISCO Masterplans ist!
Alles von CISCO (Phones, Cisco Unified Communications Manager, Netzwerkequipment) -> Alles gut.
Gemischte Umgebung -> Aufgezwungene Frickelei.
Wenn ich damit experimentiere, sendet Das Cisco SIP Requests an die IP des TFTP (mein PC). Muss ich jetzt auch nicht verstehen...
Der Aufbau der 796x Configdateien ist ja generell auch ein völlig anderer, während die 797xer ja die typische "XML Syntax" vorschreiben.
Ich glaube, dass man dadurch mit Anführungszeichen und Co nicht weiterkommt.
Der Sipgate Support hat ja selbst gesagt, wenn im URI Request die IP statt sipgate.de verwendet wird, dass das von denen nicht unterstützt wird.
Denk dran das du das Telefon dazu wieder resetten musst um die XML Datei zu laden beim Booten.
Das geht ganz einfach, ohne das Phone immer neu starten zu müssen.Mach ich immer, wenn ich an der Config rumspiele.
Einfach im Menü des Cisco die Einstellungen mit **# aktivieren und dann in den Netzwerksettings-IPv4-"Alternativ. TFTP Server" (Menüpunkt 16) de-/aktivieren.
Danach wird die Config erneut vom TFTP geladen und eingelesen.
Änderungen der Config sind dann sofort aktiv und das Gerät versucht sich erneut am PBX zu registrieren.
Zu dieser FQDN -> IP Umwandlung hab ich nur folgendes zum Beispiel gefunden.
http://www.cisco.com/c/en/us/td/docs/routers/asr1000/configuration/guid ...
Hier geht es genau um diese Thematik.
Aber nur in Verbindung mit Netzwerkgeräte von Cisco, die die URI-Requests manipulieren können.
So langsam glaub ich wirklich, dass das alles Teil des CISCO Masterplans ist!
Alles von CISCO (Phones, Cisco Unified Communications Manager, Netzwerkequipment) -> Alles gut.
Gemischte Umgebung -> Aufgezwungene Frickelei.
Mmmm, das ist schon komisch... Ich habe das hier an einem 7970G mal gesniffert mit der folgenden SIP Konfig (nur SIP User Auszug):
Wobei hier die 192.168.1.200 eine Asterisk Anlage ist.
Diese Part der XML Konfig im Telefon sollte bei dir der SIPgate Hostname oder die IP sein was ja oben auch der Fall ist.
Userauth hier:
Wobei hier die 77 die Nebenstellennummer der Anlage ist mit der sich der Client registriert. Bei dir wäre das dann wohl "1234567(SIPGATE-ID_ohne_den_KLammerteil)"
Ein Konfig Hinweis besagt das diese Angabe unter display name, contact, name und feature label immer identisch sein sollte zu dem was auch unter auth name steht !
auth name ist das was das Telefon auch raussendet an den SIP Host, das kann man mit dem Wireshark klar messen und da geht gar nix an den TFTP Server egal was da drinsteht. War hier am 70er Phone nicht nachvollziehbar !!
Lokal ist hier NAT deaktiviert:
und Zusätzlich noch
aktiviert, was aber vermutlich nichts mit dem IP FQDN Problem zu tun hat ?!
Dein Tip werd ich gleich mal testen mit den German locale Dateien die ich gezogen habe...
Ciscos genereller Masterplan ist das man als Kunde abhängig von den Systemen ist durch proprietäre Protokolle und Bindungen an andere Cisco Komponenten. So kommst du nicht mehr los von deren Fliegenfänger...das ist aber mittlerweile ja allseits bekannt.
Trotzdem müssen diese Telefone und der Callmanager ja in einem SIP Umfeld integrierbar sein. Gut möglich aber das der Call manager dann diese Umwandlungen steuert ?! Wer weiss....
Ein Termi Kabel für das Telefon ist aber hilfreich, denn dann kann man erstmal so richtig sehen was das alles so macht beim Booten.
Noch eine wichtige Frage zur Lokalisierung auf Deutsch:
Die Dateien td-sip.jar und g3-tones.xml kommen die im TFTP Bootverzeichnis in Unterverzeichnisse German_Germany bzw. Germany oder auch ganz normal in die TFTP Hauptroot oder wie ist die Liste oben von dir zu interpretieren ?
<callManagerGroup>
<members>
<member priority="0">
<callManager>
<ports>
<ethernetPhonePort>2000</ethernetPhonePort>
<sipPort>5060</sipPort>
<securedSipPort>5061</securedSipPort>
</ports>
<processNodeName>192.168.1.200</processNodeName>
</callManager>
</member>
</members>
</callManagerGroup>
Diese Part der XML Konfig im Telefon sollte bei dir der SIPgate Hostname oder die IP sein was ja oben auch der Fall ist.
Userauth hier:
<phoneLabel>7970Phone</phoneLabel>
<sipLines>
<line button="1">
<featureID>9</featureID>
<featureLabel>77</featureLabel>
<name>77</name>
<displayName>77</displayName>
<contact>77</contact>
<proxy>USECALLMANAGER</proxy>
<port>5060</port>
<autoAnswer>
<autoAnswerEnabled>2</autoAnswerEnabled>
</autoAnswer>
<callWaiting>3</callWaiting>
<authName>77</authName>
<authPassword>Geheim</authPassword>
<sharedLine>false</sharedLine>
<messageWaitingLampPolicy>1</messageWaitingLampPolicy>
<messagesNumber>*97</messagesNumber>
<ringSettingIdle>4</ringSettingIdle>
<ringSettingActive>5</ringSettingActive>
<forwardCallInfoDisplay>
<callerName>true</callerName>
<callerNumber>true</callerNumber>
<redirectedNumber>false</redirectedNumber>
<dialedNumber>true</dialedNumber>
</forwardCallInfoDisplay>
</line>
<line button="2">
<featureID>2</featureID>
<featureLabel>Oma Grete</featureLabel>
<speedDialNumber>01234567</speedDialNumber>
</line>
<line button="3">
<featureID>2</featureID>
<featureLabel>Onkel Herbert</featureLabel>
<speedDialNumber>01234567</speedDialNumber>
</line>
<line button="4">
<featureID>2</featureID>
<featureLabel>Mutti</featureLabel>
<speedDialNumber>01234567</speedDialNumber>
</line>
</sipLines>
Ein Konfig Hinweis besagt das diese Angabe unter display name, contact, name und feature label immer identisch sein sollte zu dem was auch unter auth name steht !
auth name ist das was das Telefon auch raussendet an den SIP Host, das kann man mit dem Wireshark klar messen und da geht gar nix an den TFTP Server egal was da drinsteht. War hier am 70er Phone nicht nachvollziehbar !!
Lokal ist hier NAT deaktiviert:
<natEnabled>false</natEnabled>
<natAddress></natAddress>
<transportLayerProtocol>4</transportLayerProtocol>
Das geht ganz einfach, ohne das Phone immer neu starten zu müssen.
Normal must du das Phone ja stromlos machen, den # Knopf gedrückt halten und dann senn die Line Buttons Lichtorgel spielen 123456... eintippen.Dein Tip werd ich gleich mal testen mit den German locale Dateien die ich gezogen habe...
So langsam glaub ich wirklich, dass das alles Teil des CISCO Masterplans ist!
Ja, das sagen sie ja selber das diese Telefone eigentlich nur für das Zusammenspiel mit dem Callmanager gemacht sind !!Ciscos genereller Masterplan ist das man als Kunde abhängig von den Systemen ist durch proprietäre Protokolle und Bindungen an andere Cisco Komponenten. So kommst du nicht mehr los von deren Fliegenfänger...das ist aber mittlerweile ja allseits bekannt.
Trotzdem müssen diese Telefone und der Callmanager ja in einem SIP Umfeld integrierbar sein. Gut möglich aber das der Call manager dann diese Umwandlungen steuert ?! Wer weiss....
Ein Termi Kabel für das Telefon ist aber hilfreich, denn dann kann man erstmal so richtig sehen was das alles so macht beim Booten.
Noch eine wichtige Frage zur Lokalisierung auf Deutsch:
Die Dateien td-sip.jar und g3-tones.xml kommen die im TFTP Bootverzeichnis in Unterverzeichnisse German_Germany bzw. Germany oder auch ganz normal in die TFTP Hauptroot oder wie ist die Liste oben von dir zu interpretieren ?
Meine Config is ja eigentlich gleich.
Registrieren klappt ja auch erfolgreich.
Bei "display name" macht mein Nachname oder die Sipgate ID keinen unterschied. Gerade getestet.
Wenn ich NAT im Cisco deaktiviere, gehen Register Requests an Sipgate raus und das wird auch mit dem typischen "Status-Line: SIP/2.0 401 Unauthorized" mit zugehöriger Aufforderung zu Authenticate mit "realm" und "nonce ("WWW-Authenticate: Digest realm="sipgate.de", nonce="hierstehen_Zahlen_und_Buchstaben"") beantwortet.
Aber das Cisco geht dann darauf gar nicht ein und schickt wieder einen Register Request ohne die von Sipgate zuvor geforderte Authentifizierung entsprechend zu beantworten.
Mit NAT aktiviert funktioniert der Ablauf so wie es das SIP Protokoll vorsieht.
Die 2 steht für UDP.
Das ist wohl notwendig, da ab einer bestimmten Firmware Version das Cisco mit Sipfirmware standardmäßig TCP anstatt UDP nutzt.
Und Sipgate unterstützt TCP glaube ich nicht.
Doch wenn ich die komplett verstehen will, brauche ich wohl erst noch die Cisco IP Phone Zertifizierung...
Aber hast du bestimmt schon ausprobiert und bereits die deutsche locale am laufen.
Die Anfragen des Cisco am TFTP nach den *.tlv Dateien ignoriere ich übrigens, da es sich wohl nur um Zertifikatsdateien im Zusammenspiel mit dem Cisco Call Manager handelt.
Habe jetzt auch noch ein wenig nach dem Thema FQDN -> IP Translation mit Cisco Phones gesucht, aber leider ohne Erfolg.
Registrieren klappt ja auch erfolgreich.
Ein Konfig Hinweis besagt das diese Angabe unter display name, contact, name und feature label immer identisch sein sollte zu dem was auch unter auth name steht !
Das "feature label" ist ja nur das, was im Display für die line angezeigt werden soll.Bei "display name" macht mein Nachname oder die Sipgate ID keinen unterschied. Gerade getestet.
auth name ist das was das Telefon auch raussendet an den SIP Host, das kann man mit dem Wireshark klar messen und da geht gar nix an den TFTP Server egal was da drinsteht. War hier am 70er Phone nicht nachvollziehbar !!
Das Phänomen hatte ich nur, als ich mit Anführungszeichen und Co experimentiert habe...Lokal ist hier NAT deaktiviert
Das muss ich bei mir aktivieren, sonst funktioniert die Registrierung bei Sipgate nicht.Wenn ich NAT im Cisco deaktiviere, gehen Register Requests an Sipgate raus und das wird auch mit dem typischen "Status-Line: SIP/2.0 401 Unauthorized" mit zugehöriger Aufforderung zu Authenticate mit "realm" und "nonce ("WWW-Authenticate: Digest realm="sipgate.de", nonce="hierstehen_Zahlen_und_Buchstaben"") beantwortet.
Aber das Cisco geht dann darauf gar nicht ein und schickt wieder einen Register Request ohne die von Sipgate zuvor geforderte Authentifizierung entsprechend zu beantworten.
Mit NAT aktiviert funktioniert der Ablauf so wie es das SIP Protokoll vorsieht.
und Zusätzlich noch
01. <transportLayerProtocol>4</transportLayerProtocol>
aktiviert, was aber vermutlich nichts mit dem IP FQDN Problem zu tun hat ?!
Die 4 sagt nur, dass TCP bevorzugt wird.01. <transportLayerProtocol>4</transportLayerProtocol>
aktiviert, was aber vermutlich nichts mit dem IP FQDN Problem zu tun hat ?!
Die 2 steht für UDP.
Das ist wohl notwendig, da ab einer bestimmten Firmware Version das Cisco mit Sipfirmware standardmäßig TCP anstatt UDP nutzt.
Und Sipgate unterstützt TCP glaube ich nicht.
Trotzdem müssen diese Telefone und der Callmanager ja in einem SIP Umfeld integrierbar sein. Gut möglich aber das der Call manager dann diese Umwandlungen steuert ?! Wer weiss....
Das vermute ich auch.Ein Termi Kabel für das Telefon ist aber hilfreich, denn dann kann man erstmal so richtig sehen was das alles so macht beim Booten.
Wenn das Webinterface aktiviert ist, kann man auch auf alle logs unter Geräteprotokolle-Konsolenprotokolle zugreifen.Doch wenn ich die komplett verstehen will, brauche ich wohl erst noch die Cisco IP Phone Zertifizierung...
Noch eine wichtige Frage zur Lokalisierung auf Deutsch:
Die Dateien td-sip.jar und g3-tones.xml kommen die im TFTP Bootverzeichnis in Unterverzeichnisse German_Germany bzw. Germany oder auch ganz normal in die TFTP Hauptroot oder wie ist die Liste oben von dir zu interpretieren ?
Jeweils ins darüberstehende Unterverzeichnis.Die Dateien td-sip.jar und g3-tones.xml kommen die im TFTP Bootverzeichnis in Unterverzeichnisse German_Germany bzw. Germany oder auch ganz normal in die TFTP Hauptroot oder wie ist die Liste oben von dir zu interpretieren ?
Aber hast du bestimmt schon ausprobiert und bereits die deutsche locale am laufen.
Die Anfragen des Cisco am TFTP nach den *.tlv Dateien ignoriere ich übrigens, da es sich wohl nur um Zertifikatsdateien im Zusammenspiel mit dem Cisco Call Manager handelt.
Habe jetzt auch noch ein wenig nach dem Thema FQDN -> IP Translation mit Cisco Phones gesucht, aber leider ohne Erfolg.
http://www.voip-info.org/wiki/view/SIP+URI
host: The host providing the SIP resource. The host part contains either a fully-qualified domain name or numeric IPv4 or IPv6 address. Using the fully-qualified domain name form is RECOMMENDED whenever possible.
Soso, Cisco.^^Wenn das Webinterface aktiviert ist, kann man auch auf alle logs unter Geräteprotokolle-Konsolenprotokolle zugreifen.
Oha, nein über das Webinterface siehst du nur einen minimalen Bruchteil.Die Consol Meldungen sind ungefähr Faktor 10 mehr....
Using the fully-qualified domain name form is RECOMMENDED whenever possible.
Ha ha ha...da hörst du es doch. Sie empfehlen das selber....habens aber wohl nie probiert ?!?Ich richte jetzt mal die deutsche Sprache (hatte noch auf dein "HowTo" gewartet) auf dem 7970er hier ein und werde meinen User mal auf einen mit FQDN umstellen und mal sniffern (und berichten) was der raussendet
Hi,
leider hat sich aqui nicht mehr gemeldet.
Er wollte das ja auch nachstellen.
Also die config, die ich bereits gepostet habe "funktioniert".
Cisco IP Phone 7975 einrichten, wer kann helfen? (zum 2.)
Problem ist halt immer noch, dass der Register Request mit der aufgelösten IP und nicht mit dem FQDN sipgate.de stattfindet und deshalb trotz erfolgreicher Registrierung am Sipgate PBX keine ankommende anrufe durchgeleitet werden. (serverseitig von Sipgate)
Dieses Problem konnte ich nicht lösen.
Werde deshalb vermutlich mit nem Raspberry Pi oder so Asterisk dazwischen schalten.
Dann funktioniert das Cisco auch mit der SCCP Firmware, was wohl generell besser durch Cisco supportet wird.
leider hat sich aqui nicht mehr gemeldet.
Er wollte das ja auch nachstellen.
Also die config, die ich bereits gepostet habe "funktioniert".
Cisco IP Phone 7975 einrichten, wer kann helfen? (zum 2.)
Problem ist halt immer noch, dass der Register Request mit der aufgelösten IP und nicht mit dem FQDN sipgate.de stattfindet und deshalb trotz erfolgreicher Registrierung am Sipgate PBX keine ankommende anrufe durchgeleitet werden. (serverseitig von Sipgate)
Dieses Problem konnte ich nicht lösen.
Werde deshalb vermutlich mit nem Raspberry Pi oder so Asterisk dazwischen schalten.
Dann funktioniert das Cisco auch mit der SCCP Firmware, was wohl generell besser durch Cisco supportet wird.
Zeitmangel...sorry
Folgende Konfig hab ich auf einem Cisco 7961 verwendet:
Wobei "SIP-ID" mit der SIPgate ID Nummer und "Passwort" mit dem Passwort ersetzt wurde.
Effekt ist aber wie beschrieben: Ausgehende Calls funktionieren fehlerlos... Eingehende Calls werden mit der Angabe "Nummer nicht erreichbar" quittiert.
Sieht man sich den Account Status bei SIPgate an steht dort "Offline". Es kommt also kein bidirektionales SIP Handshaking zustande.
Ich habe mir mit dem Wireshark jetzt noch nicht die entsprechenden Live Daten angesehen die das Telefon sendet....kommt aber noch.
Testen geht also weiter...
Nebenbei: Um auch ein 7961-G auf Deutsch umzustellen muss man noch die Datei mk-sip.jar in das Verzeichnis "German_Germany" im TFTP Server kopieren
Hier ist übrigens noch eine sehr gute Doku von einem der es hinbekommen hat:
http://adriansauer.com/2008/12/06/meine-cisco-cp-7960g-konfiguration/
Der Schlüssel zum Erfolg ist vermutlich das er eine DynDNS Adresse statt der IP beim NAT eingerichtet hat. Müsste man mal testen.
Es müsste aber auch mit der Tages IP gehen die man mit http://www.heise.de/netze/tools/meine-ip-adresse/ ja rausbekommt !
Folgende Konfig hab ich auf einem Cisco 7961 verwendet:
<callManager>
<ports>
<ethernetPhonePort>2000</ethernetPhonePort>
<sipPort>5060</sipPort>
<securedSipPort>5061</securedSipPort>
</ports>
<processNodeName>sipgate.de</processNodeName>
</callManager>
<sipProxies>
<backupProxy></backupProxy>
<backupProxyPort></backupProxyPort>
<emergencyProxy></emergencyProxy>
<emergencyProxyPort></emergencyProxyPort>
<outboundProxy>sipgate.de</outboundProxy>
<outboundProxyPort>5060</outboundProxyPort>
<registerWithProxy>true</registerWithProxy>
</sipProxies>
<natEnabled>true</natEnabled>
<transportLayerProtocol>2</transportLayerProtocol>
<phoneLabel>7961Phone</phoneLabel>
<sipLines>
<line button="1">
<featureID>9</featureID>
<featureLabel>SIP-ID</featureLabel>
<name>SIP-ID</name>
<displayName>SIP-ID</displayName>
<contact>SIP-ID</contact>
<proxy>USECALLMANAGER</proxy>
<port>5060</port>
<autoAnswer>
<autoAnswerEnabled>2</autoAnswerEnabled>
</autoAnswer>
<callWaiting>3</callWaiting>
<authName>SIP-ID</authName>
<authPassword>SIPgate-Password</authPassword>
Effekt ist aber wie beschrieben: Ausgehende Calls funktionieren fehlerlos... Eingehende Calls werden mit der Angabe "Nummer nicht erreichbar" quittiert.
Sieht man sich den Account Status bei SIPgate an steht dort "Offline". Es kommt also kein bidirektionales SIP Handshaking zustande.
Ich habe mir mit dem Wireshark jetzt noch nicht die entsprechenden Live Daten angesehen die das Telefon sendet....kommt aber noch.
Testen geht also weiter...
Nebenbei: Um auch ein 7961-G auf Deutsch umzustellen muss man noch die Datei mk-sip.jar in das Verzeichnis "German_Germany" im TFTP Server kopieren
Hier ist übrigens noch eine sehr gute Doku von einem der es hinbekommen hat:
http://adriansauer.com/2008/12/06/meine-cisco-cp-7960g-konfiguration/
Der Schlüssel zum Erfolg ist vermutlich das er eine DynDNS Adresse statt der IP beim NAT eingerichtet hat. Müsste man mal testen.
Es müsste aber auch mit der Tages IP gehen die man mit http://www.heise.de/netze/tools/meine-ip-adresse/ ja rausbekommt !