Liebes IP Forum, ich habe seit einigen Jahren eine Fritz Box 7390 mit mehreren Cisco 7970 erfolgreich im Betrieb. Das System läuft sehr stabil und ohne Probleme. Auch die letzten OS Updates von AVM auf der Fritz Box haben keine Probleme mit sich gebracht. Das letzte Update (Fritz OS 6.80) gestern Abend hat aber Probleme mit dem Phones verursacht…. ! Die Ciscos haben sich nicht mehr an der FB anmelden können. Wurden aber in der Netzwerkübersicht als verbunden angezeigt. Es ist mir dann leider nicht gelungen, die Ciscos 7970 wieder mit der FB und der aktuellen OS 6.80 in Funktion zu bringen. Einzige Lösung war nur ein Downgrade auf die Vorgänger OS Version! Damit läuft das System jetzt wieder zu 100%. Meine Frage an alle, kennt jemand auch schon das Problem mit der neuen Version Fritz OS 6.80 in Kombination mit Cisco Phones ?? Würde mich über ein paar Rückmeldungen sehr freuen! Wär ja sehr schade wenn die neuere OS Versionen nicht mehr mit den Ciscos und SIP laufen! Kennt jemand eine Lösung?! Grüße
nur mal so ins Blaue, die Info ueber die Mindestlaenge des SIP Passworts ab FW 6.80 hast Du gelesen und Dein Passwort ist lang genug?
Hallo Mckey, besten Dank für deinen Hinweis !! Ah, das könnt es sein !!! Aktuell bzw. seit Jahren nur dreistellig! Dann muss aber das Passwort in der SEP auch entsprechend angepasst werden ! Ich versuche mal mein Glück! Grüße
Hallo, ich habe exakt das gleiche Problem. Das Kennwort für das IP-Phone in der Fritzbox sowie in der Konfig im Gerät habe ich inzwischen neu gesetzt - leider noch immer ohne Erfolg. Das C7961 will sich einfach nicht mehr verbinden. Hat noch jemand einen Tipp?
Kennwort ist 15 stellig mit Groß- Kleinschreibung und Ziffern. Fehlt noch was? Die FB zeigt bei der Vergabe grün an... FritzFon vom iPhone verbindet sich und funtioniert. Nur das Cisco Gerät nicht. Im Log der FB kann ich nichts finden - die Verbindungen vom FritzFon werden gezeigt.
Hallo an alle , ich freue mich, dass ich nicht alleine mit dem Problem bin. So kommen wir vielleicht schneller zu einer Lösung! Vielleicht das Phone in der FB einfach mal komplett neu anmelden ? Was passiert dann? Ich will meine FB noch nicht updaten sofern das Problem noch keine Lösung hat. Die Alternative wäre auf ein neues Update von FB zu warten und dann solange die alte OS Version nutzen! Grüße - - - Aktualisiert - - - Vielleicht haben sich bei der FB einfach mit dem Update bestimmte Parameter oder Befehle die dann die FB für SIP Phones benötigt geändert?? Alternative ist noch AVM zu kontaktieren und dort mal zu fragen, welche Änderungen sich mit dem OS 6.80 Update in Verbindung mit SIP IP Phones ergeben. Grüße
Hallo, ich habe leider auch dieses Problem. Passwort in der Fritz Box und in der sep.xml habe ich geändert, leider ohne Erfolg. Ich habe dann mal die Seite fritz.box/support.lua aufgerufen und mir eine erweiterte Log Datei erstellt. Dabei fällt folgendes auf: Content-Len2017-02-13 12:31:06.840 - OUT: my=(null) peer=192.168.178.45 port=52906 TCP, sipiface=none tcclass=sip, netmark=0: SIP/2.0 400 Parser memory problem Via: SIP/2.0/TCP 192.168.178.45:52906;branch=z9hG4bK05f18ab4 From: <sip:[email protected]>;tag=001c58f9c4f00005d0be3130-7a0c2944 To: <sip:[email protected]>;tag=badrequest Call-ID: [email protected] CSeq: 103 REGISTER User-Agent: FRITZ!OS Content-Length: 0 2017-02-13 12:31:06.842 - IN: my=(null) peer=192.168.178.45 port=52906 TCP, sipiface=none: (null) 2017-02-13 12:31:06.842 - OUT: my=(null) peer=192.168.178.45 port=52906 TCP, sipiface=none tcclass=sip, netmark=0: SIP/2.0 400 Illegal request line From: <sip:missing> To: <sip:missing>;tag=badrequest User-Agent: FRITZ!OS Content-Length: 0 ---------------------------------- Wieso eigentlich port=52906 TCP? Müsste da nicht 5060 UDP stehen? Sorry, bin nicht völlig im Thema, aber beim anderen Telefon welches sich korrekt anmeldet steht dort eben UDP. Kann mit den anderen Fehlermeldungen vielleicht jemand etwas anfangen? Übrigens: Ich habe auch schon das Telefon komplett aus der Fritz Box gelöscht und neu angelegt, leider auch ohne Erfolg.
Hallo, ändere doch den Port bei der SEP Datei deines Ciscos auf Port 52906 statt 5060 !!Was passiert dann ?
Dazu sollte noch ein Eintrag davor gehören ... vermutlich stehen dort irgendwo zuviele "Alternativen" in irgendeinem Header oder im Body (vielleicht bei den Codecs?) und der Parser kommt damit nicht mehr klar. Je nachdem, was nun wirklich in dem bemängelten Request steht (und wo dann vermutlich dieses "out of memory" auftritt), müßte man dann die passende Einstellung im SIP-Client verändern.
[QUOTE/] Je nachdem, was nun wirklich in dem bemängelten Request steht (und wo dann vermutlich dieses "out of memory" auftritt), müßte man dann die passende Einstellung im SIP-Client verändern.[/QUOTE] Also in der SEP des Cisco Phones ??
OK, hier mal der Eintrag des Logs von der Fritz Box: 2017-02-13 12:31:06.839 - IN: my=(null) peer=192.168.178.45 port=52906 TCP, sipiface=none: REGISTER sip:192.168.178.1 2.0 Via: SIP/2.0/TCP 192.168.178.45:52906;branch=z9hG4bK05f18ab4 From: <sip:[email protected]>;tag=001c58f9c4f00005d0be3130-7a0c2944 To: <sip:[email protected]> Call-ID: [email protected] CSeq: 103 REGISTER Contact: <sip:[email protected]:52906;transport=tcp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-001c58f9c4f0>";+u.sip!devicename.ccm.cisco.com="SEP001C58F9C4F0";+u.sip!model.ccm.cisco.com="30018" Max-Forwards: 70 Date: Mon, 13 Feb 2017 11:31:06 GMT User-Agent: Cisco-CP7961G/9.4.2 Supported: replaces Supported: join Supported: sdp-anat Supported: norefersub Supported: resource-priority Supported: extended-refer Supported: X-cisco-callinfo Supported: X-cisco-serviceuri Supported: X-cisco-escapecodes Supported: X-cisco-service-control Supported: X-cisco-srtp-fallback Supported: X-cisco-monrec Supported: X-cisco-config Supported: X-cisco-sis-6.0.0 Supported: X-cisco-xsi-8.5.1 Reason: SIP;cause=200;text="cisco-alarm:24 Name=SEP001C58F9C4F0 Load=SIP41.9-4-2SR2-2S Last=phone-reg-rej" Expires: 300 Content-Type: multipart/mixed; boundary=uniqueBoundary Mime-Version: 1.0 Content-Len2017-02-13 12:31:06.840 - OUT: my=(null) peer=192.168.178.45 port=52906 TCP, sipiface=none tcclass=sip, netmark=0: SIP/2.0 400 Parser memory problem Via: SIP/2.0/TCP 192.168.178.45:52906;branch=z9hG4bK05f18ab4 From: <sip:[email protected]>;tag=001c58f9c4f00005d0be3130-7a0c2944 To: <sip:[email protected]>;tag=badrequest Call-ID: [email protected] CSeq: 103 REGISTER User-Agent: FRITZ!OS Content-Length: 0 Hmmm....
Moinsen Die Fritz!Box schmettert so bspw. "zu lange" Klient-Codeclisten (bei einem INVITE) ab. Siehe: http://www.ip-phone-forum.de/showthread.php?t=290261&p=2206336&viewfull=1#post2206336
Ich weiß zwar nicht, wie man die ganzen "Supported: X-cisco-irgendwas"-Einträge am Ende "abstellt", aber ich halte es für sehr unwahrscheinlich, daß die FRITZ!Box mit diesen Einträgen etwas anfangen kann und dann müssen die auch nicht im REGISTER-Request auftauchen. Ob das FRITZ!OS einzelne dieser Optionen tatsächlich kennt, sollte ja schon ein "grep" über die entpackte Firmware zeigen ... für die Erkennung einer Option muß die ja dann auch irgendwo "hinterlegt" sein, ggf. ohne den "X-cisco"-Zusatz (der vielleicht nur einmal existert, aber auch dieses eine Mal konnte ich zumindest nicht finden, nur einzelnes "cisco" findet sich tatsächlich, aber an zwei vollkommen anderen Stellen). Die eigentliche Fehlerbedingung und die Nachricht existiert auch schon ewig ... man kann nur spekulieren (oder müßte es sehr systematisch testen), welche zusätzlichen Limits AVM da nun wohl eingezogen hat - vielleicht konnte man einfach mit zuvielen Einträgen irgendwelche Buffer- oder Stack-Overflows erreichen; zum eigentlichen Parsen des Requests verwendet AVM wohl die "libosip2", welche (schon ältere) OpenSource-Software ist. Wobei 15 "Supported"-Header auch schon ziemlich heftig sind, schließlich ist die Darstellung als kommaseparierte Liste ebenfalls erlaubt - auch wenn ich nicht weiß, ob sich der Parser an der Anzahl der Header oder an der Anzahl der Werte stört.
Hallo PeterPawn, besten Dank für die Antwort ! Leider stehe bei der Antwort total im Wald ! Da komme ich nicht mehr mit... ! Grüße
Wie soll man denn eine konkrete Empfehlung geben, solange man keine Informationen hat? Insofern ging das eigentlich eher an @jimpansen, auch wenn der Thread mal von @thomaskino eröffnet wurde. Woher kommt denn die Konfiguration des Cisco-Telefons (CUCM oder irgendein eigener TFTP-Server?) und wie sieht sie aus? Ich kenne auch nicht alle Optionen, die man bei so einem Teil über die XML-Struktur konfigurieren kann, aber es sind viele, viele Möglichkeiten. Woher soll man hier wissen, was da konkret konfiguriert ist? Die Vermutung ist es halt, daß es zuviele "Supported"-Header in der Message sind (wenn das bei @thomaskino überhaupt dasselbe Problem ist, der Auszug aus dem SIP-Protokoll der FRITZ!Box ist ja von @jimpansen und die einzige bisher greifbare "Spur" abseits von "geht nicht") und nun muß man sich eben informieren, wie man deren Anzahl reduzieren kann. Das hängt sicherlich davon ab, was die "Standardeinstellung" des Telefons ist. Muß man alle "Cisco-Spezialitäten" erst "zuschalten", läßt man einfach die betreffenden Einträge in der Konfigurationsdatei weg - sind die standardmäßig aktiv und man kann sie abschalten (auch das weiß ich nicht, steht aber bestimmt irgendwo bei Cisco), dann muß man die betreffenden Anweisungen der Konfigurationsdatei hinzufügen. Die Frage ist doch, ob es darum geht, einen Hinweis auf die mögliche Ursache zu erhalten oder eine fertige Lösung. Ich habe mich bemüht, für die Meldung in #8 (das war eben der erste konkrete Fehler, der hier überhaupt auftauchte) eine mögliche Erklärung zu liefern. Die muß nicht einmal stimmen ... ob das jetzt jemand für wahrscheinlich hält und dann entsprechend bei sich probiert (unter dem Damoklesschwert des möglichen Mißerfolgs), muß jeder ohnehin selbst entscheiden. AVM kann auch genauso gut einfach übersehen haben, daß bei den Cisco-Telefonen die Liste der Header vielleicht gar nicht zu beeinflussen ist (also das OS dort immer alle Optionen offeriert) und daß nun ein neues Limit für den Parser diese Telefone komplett abhängt. Entweder man fragt AVM ganz konkret, wie die Limits für die einzelnen Header in einem REGISTER-Request bei der 06.80 nun aussehen (bzw. was im eigenen konkreten Request dieses "Parser memory problem" verursacht) und hofft auf eine (inhaltlich richtige) Antwort, die einen weiterbringt oder man geht selbst ans Experimentieren und versucht die passenden Einstellungen (eben am SIP-Client) zu finden. Das muß sicherlich kein "blindes Probieren" sein, wenn man wenigstens eine Idee (bzw. eben eine Theorie) hat, woran es liegen könnte.
Hallo, @PeterPawn, vielen Dank erst mal für die Mühe sich überhaupt mit dem Problem zu beschäftigen. Das ist ja nicht einmal Dein Problem Also Danke! Ich habe hier mal meine komplette sep.cnf.xml kopiert: Code: <?xml version="1.0" encoding="UTF-8"?> <device xsi:type="axl:XIPPhone" ctiid="7" uuid="{89b84111-68bf-4498-8233-d9935482e0f2}"> <fullConfig>true</fullConfig> <deviceProtocol>SIP</deviceProtocol> <sshUserId>admin</sshUserId> <sshPassword>xxxx</sshPassword> <ipAddressMode>0</ipAddressMode> <allowAutoConfig>true</allowAutoConfig> <ipPreferenceModeControl>0</ipPreferenceModeControl> <tzdata> <tzolsonversion>2009p</tzolsonversion> <tzupdater></tzupdater> </tzdata> <featurePolicyFile>DefaultFP.xml</featurePolicyFile> <devicePool uuid="{1b1b9eb6-7803-11d3-bdf0-00108302ead1}"> <revertPriority>0</revertPriority> <name>Default</name> <dateTimeSetting> <name>W.Europe</name> <dateTemplate>D/M/Y</dateTemplate> <timeZone>W. Europe Standard/Daylight Time</timeZone> <ntps> <ntp> <name>131.234.137.23</name> <ntpMode>Unicast</ntpMode> </ntp> <ntp> <name>192.53.103.108</name> <ntpMode>Unicast</ntpMode> </ntp> </ntps> </dateTimeSetting> <callManagerGroup> <name>Default</name> <tftpDefault>true</tftpDefault> <members> <member priority="0"> <callManager> <name>CUCM</name> <description>CUCM</description> <ports> <ethernetPhonePort>2000</ethernetPhonePort> <sipPort>5060</sipPort> </ports> <processNodeName>fritz.box</processNodeName> </callManager> </member> </members> </callManagerGroup> <srstInfo uuid="{cd241e11-4a58-4d3d-9661-f06c912a18a3}"> <name>Enable</name> <srstOption>Enable</srstOption> <userModifiable>true</userModifiable> <ipAddr1>fritz.box</ipAddr1> <port1>2000</port1> <ipAddr2></ipAddr2> <port2>2000</port2> <ipAddr3></ipAddr3> <port3>2000</port3> <sipIpAddr1>fritz.box</sipIpAddr1> <sipPort1>5060</sipPort1> <sipIpAddr2></sipIpAddr2> <sipPort2>5060</sipPort2> <sipIpAddr3></sipIpAddr3> <sipPort3>5060</sipPort3> <isSecure>true</isSecure> </srstInfo> <mlppDomainId>-1</mlppDomainId> <mlppIndicationStatus>Default</mlppIndicationStatus> <preemption>Default</preemption> <connectionMonitorDuration>120</connectionMonitorDuration> </devicePool> <TVS> <members> <member priority="0"> <port>2445</port> <address>fritz.box</address> </member> </members> </TVS> <sipProfile> <sipProxies> <backupProxy>USECALLMANAGER</backupProxy> <backupProxyPort>5060</backupProxyPort> <emergencyProxy>USECALLMANAGER</emergencyProxy> <emergencyProxyPort>5060</emergencyProxyPort> <outboundProxy>USECALLMANAGER</outboundProxy> <outboundProxyPort>5060</outboundProxyPort> <registerWithProxy>true</registerWithProxy> </sipProxies> <sipCallFeatures> <cnfJoinEnabled>true</cnfJoinEnabled> <callForwardURI>x-cisco-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> <retainForwardInformation>false</retainForwardInformation> </sipCallFeatures> <sipStack> <sipInviteRetx>6</sipInviteRetx> <sipRetx>10</sipRetx> <timerInviteExpires>180</timerInviteExpires> <timerRegisterExpires>300</timerRegisterExpires> <timerRegisterDelta>5</timerRegisterDelta> <timerKeepAliveExpires>120</timerKeepAliveExpires> <timerSubscribeExpires>120</timerSubscribeExpires> <timerSubscribeDelta>5</timerSubscribeDelta> <timerT1>500</timerT1> <timerT2>4000</timerT2> <maxRedirects>70</maxRedirects> <remotePartyID>true</remotePartyID> <userInfo>625</userInfo> </sipStack> <autoAnswerTimer>0</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> <kpml>3</kpml> <natEnabled>false</natEnabled> <phoneLabel>WandKueche</phoneLabel> <stutterMsgWaiting>0</stutterMsgWaiting> <callStats>true</callStats> <offhookToFirstDigitTimer>15000</offhookToFirstDigitTimer> <T302Timer>15000</T302Timer> <silentPeriodBetweenCallWaitingBursts>10</silentPeriodBetweenCallWaitingBursts> <disableLocalSpeedDialConfig>false</disableLocalSpeedDialConfig> <poundEndOfDial>true</poundEndOfDial> <startMediaPort>16384</startMediaPort> <stopMediaPort>32766</stopMediaPort> <sipLines> <line button="1" lineIndex="1"> <featureID>9</featureID> <featureLabel>625</featureLabel> <proxy>USECALLMANAGER</proxy> <port>5060</port> <name>625</name> <displayName>625</displayName> <autoAnswer> <autoAnswerEnabled>2</autoAnswerEnabled> </autoAnswer> <callWaiting>3</callWaiting> <authName>625</authName> <authPassword>xxxxx</authPassword> <sharedLine>false</sharedLine> <messageWaitingLampPolicy>1</messageWaitingLampPolicy> <messageWaitingAMWI>0</messageWaitingAMWI> <messagesNumber>**600</messagesNumber> <ringSettingIdle>4</ringSettingIdle> <ringSettingActive>5</ringSettingActive> <contact>625</contact> <forwardCallInfoDisplay> <callerName>true</callerName> <callerNumber>false</callerNumber> <redirectedNumber>false</redirectedNumber> <dialedNumber>true</dialedNumber> </forwardCallInfoDisplay> <maxNumCalls>4</maxNumCalls> <busyTrigger>2</busyTrigger> </line> <line button="2" lineIndex="2"> <featureID>9</featureID> <featureLabel>626</featureLabel> <proxy>USECALLMANAGER</proxy> <port>5060</port> <name>626</name> <displayName>626</displayName> <autoAnswer> <autoAnswerEnabled>2</autoAnswerEnabled> </autoAnswer> <callWaiting>3</callWaiting> <authName>626</authName> <authPassword>xxxxxx</authPassword> <sharedLine>false</sharedLine> <messageWaitingLampPolicy>1</messageWaitingLampPolicy> <messageWaitingAMWI>0</messageWaitingAMWI> <messagesNumber>**600</messagesNumber> <ringSettingIdle>4</ringSettingIdle> <ringSettingActive>5</ringSettingActive> <contact>626</contact> <forwardCallInfoDisplay> <callerName>true</callerName> <callerNumber>false</callerNumber> <redirectedNumber>false</redirectedNumber> <dialedNumber>true</dialedNumber> </forwardCallInfoDisplay> <maxNumCalls>4</maxNumCalls> <busyTrigger>2</busyTrigger> </line> <line button="3"> <featureID>21</featureID> <featureLabel>Stall</featureLabel> <speedDialNumber>**624</speedDialNumber> <featureOptionMask>1</featureOptionMask> </line> <line button="4"> <featureID>21</featureID> <featureLabel>Arbeitszimmer</featureLabel> <speedDialNumber>**627</speedDialNumber> <featureOptionMask>1</featureOptionMask> </line> <line button="5"> <featureID>21</featureID> <featureLabel>Mobil Kueche</featureLabel> <speedDialNumber>**612</speedDialNumber> <featureOptionMask>1</featureOptionMask> </line> <line button="6"> <featureID>21</featureID> <featureLabel>Mobil Wohnzimmer</featureLabel> <speedDialNumber>**613</speedDialNumber> <featureOptionMask>1</featureOptionMask> </line> </sipLines> <externalNumberMask></externalNumberMask> <voipControlPort>5061</voipControlPort> <dscpForAudio>184</dscpForAudio> <dscpVideo>136</dscpVideo> <dscpForTelepresence>128</dscpForTelepresence> <ringSettingBusyStationPolicy>0</ringSettingBusyStationPolicy> <dialTemplate>dialplan.xml</dialTemplate> <softKeyFile>Softkey.xml</softKeyFile> <alwaysUsePrimeLine>false</alwaysUsePrimeLine> <alwaysUsePrimeLineVoiceMail>false</alwaysUsePrimeLineVoiceMail> </sipProfile> <MissedCallLoggingOption>99</MissedCallLoggingOption> <commonProfile> <phonePassword></phonePassword> <backgroundImageAccess>true</backgroundImageAccess> <callLogBlfEnabled>2</callLogBlfEnabled> </commonProfile> <loadInformation></loadInformation> <vendorConfig> <disableSpeaker>false</disableSpeaker> <disableSpeakerAndHeadset>false</disableSpeakerAndHeadset> <pcPort>0</pcPort> <sdio>1</sdio> <garp>1</garp> <voiceVlanAccess>0</voiceVlanAccess> <webAccess>0</webAccess> <videoCapability>1</videoCapability> <ciscoCamera>1</ciscoCamera> <spanToPCPort>1</spanToPCPort> <loggingDisplay>0</loggingDisplay> <recordingTone>0</recordingTone> <recordingToneLocalVolume>100</recordingToneLocalVolume> <recordingToneRemoteVolume>50</recordingToneRemoteVolume> <recordingToneDuration></recordingToneDuration> <displayOnWhenIncomingCall>1</displayOnWhenIncomingCall> <logServer></logServer> <g722CodecSupport>2</g722CodecSupport> <headsetWidebandUIControl>0</headsetWidebandUIControl> <headsetWidebandEnable>0</headsetWidebandEnable> <lldpAssetId></lldpAssetId> <powerPriority>0</powerPriority> <detectCMConnectionFailure>0</detectCMConnectionFailure> </vendorConfig> <commonConfig> </commonConfig> <enterpriseConfig> </enterpriseConfig> <versionStamp>1280870288-91f38f2d-7fff-4a42-87cd-76f9b4a802fc</versionStamp> <userLocale> <name>English_United_States</name> <uid>1</uid> <langCode>en_US</langCode> <version>8.0.0.1(4)</version> <winCharSet>iso-8859-1</winCharSet> </userLocale> <networkLocale>United_States</networkLocale> <networkLocaleInfo> <name>United_States</name> <uid>64</uid> <version>8.0.0.1(4)</version> </networkLocaleInfo> <deviceSecurityMode>1</deviceSecurityMode> <idleTimeout>0</idleTimeout> <authenticationURL>http://CUCM:8080/ccmcip/authenticate.jsp</authenticationURL> <directoryURL>http://CUCM:8080/ccmcip/xmldirectory.jsp</directoryURL> <idleURL></idleURL> <informationURL>http://CUCM:8080/ccmcip/GetTelecasterHelpText.jsp</informationURL> <messagesURL></messagesURL> <proxyServerURL></proxyServerURL> <servicesURL>http://CUCM:8080/ccmcip/getservicesmenu.jsp</servicesURL> <secureAuthenticationURL>https://CUCM:8443/ccmcip/authenticate.jsp</secureAuthenticationURL> <secureDirectoryURL>https://CUCM:8443/ccmcip/xmldirectory.jsp</secureDirectoryURL> <secureIdleURL></secureIdleURL> <secureInformationURL>https://CUCM:8443/ccmcip/GetTelecasterHelpText.jsp</secureInformationURL> <secureMessagesURL></secureMessagesURL> <secureServicesURL>https://CUCM:8443/ccmcip/getservicesmenu.jsp</secureServicesURL> <dscpForSCCPPhoneConfig>96</dscpForSCCPPhoneConfig> <dscpForSCCPPhoneServices>0</dscpForSCCPPhoneServices> <dscpForCm2Dvce>96</dscpForCm2Dvce> <transportLayerProtocol>1</transportLayerProtocol> <dndCallAlert>5</dndCallAlert> <phonePersonalization>1</phonePersonalization> <rollover>0</rollover> <singleButtonBarge>0</singleButtonBarge> <joinAcrossLines>0</joinAcrossLines> <autoCallPickupEnable>false</autoCallPickupEnable> <blfAudibleAlertSettingOfIdleStation>0</blfAudibleAlertSettingOfIdleStation> <blfAudibleAlertSettingOfBusyStation>0</blfAudibleAlertSettingOfBusyStation> <capfAuthMode>0</capfAuthMode> <capfList> <capf> <phonePort>3804</phonePort> <processNodeName>CUCM</processNodeName> </capf> </capfList> <certHash></certHash> <encrConfig>false</encrConfig> <advertiseG722Codec>1</advertiseG722Codec> <mobility> <handoffdn></handoffdn> <dtmfdn></dtmfdn> <ivrdn></ivrdn> <dtmfHoldCode>*81</dtmfHoldCode> <dtmfExclusiveHoldCode>*82</dtmfExclusiveHoldCode> <dtmfResumeCode>*83</dtmfResumeCode> <dtmfTxfCode>*84</dtmfTxfCode> <dtmfCnfCode>*85</dtmfCnfCode> </mobility> <userId>299</userId> <phoneServices useHTTPS="true"> <provisioning>2</provisioning> <phoneService type="1" category="0"> <name>Missed Calls</name> <url>Application:Cisco/MissedCalls</url> <vendor></vendor> <version></version> </phoneService> <phoneService type="2" category="0"> <name>Voicemail</name> <url>Application:Cisco/Voicemail</url> <vendor></vendor> <version></version> </phoneService> <phoneService type="1" category="0"> <name>Received Calls</name> <url>Application:Cisco/ReceivedCalls</url> <vendor></vendor> <version></version> </phoneService> <phoneService type="1" category="0"> <name>Placed Calls</name> <url>Application:Cisco/PlacedCalls</url> <vendor></vendor> <version></version> </phoneService> <phoneService type="1" category="0"> <name>Personal Directory</name> <url>Application:Cisco/PersonalDirectory</url> <vendor></vendor> <version></version> </phoneService> <phoneService type="1" category="0"> <name>Corporate Directory</name> <url>Application:Cisco/CorporateDirectory</url> <vendor></vendor> <version></version> </phoneService> </phoneServices> </device> ------------------------------------------------------------------------- Die Konfiguration bekommt das Telefon über eine Synology NAS und dessen TFTP Server. Das funktioniert auch, ich hatte auch schon ein Update der Sip-Firmware für das Cisco darüber eingespielt, leider hat das auch nichts gebracht. Was mich neben dieser "Parser memory" Geschichte etwas stört, ist zum einen diese Meldung im Fritz Box Log file: SIP/2.0 400 Illegal request line From: <sip:missing> To: <sip:missing>;tag=badrequest und zum anderen der TCP-Port 52906 welcher in der Cisco-XML Config überhaupt nicht vorkommt. Wieso TCP und dieser merkwürdige Port? Nochmal komplett: Code: 2017-02-13 12:31:06.842 - IN: my=(null) peer=192.168.178.45 port=52906 TCP, sipiface=none: (null) 2017-02-13 12:31:06.842 - OUT: my=(null) peer=192.168.178.45 port=52906 TCP, sipiface=none tcclass=sip, netmark=0: SIP/2.0 400 Illegal request line From: <sip:missing> To: <sip:missing>;tag=badrequest User-Agent: FRITZ!OS Content-Length: 0 2017-02-13 12:31:06.843 - IN: my=(null) peer=192.168.178.45 port=52906 TCP, sipiface=none: (null) 2017-02-13 12:31:06.843 - OUT: my=(null) peer=192.168.178.45 port=52906 TCP, sipiface=none tcclass=sip, netmark=0: SIP/2.0 400 Illegal request line From: <sip:missing> To: <sip:missing>;tag=badrequest User-Agent: FRITZ!OS Content-Length: 0 2017-02-13 12:31:06.844 - IN: my=(null) peer=192.168.178.45 port=52906 TCP, sipiface=none: (null) 2017-02-13 12:31:06.844 - OUT: my=(null) peer=192.168.178.45 port=52906 TCP, sipiface=none tcclass=sip, netmark=0: SIP/2.0 400 Illegal request line From: <sip:missing> To: <sip:missing>;tag=badrequest User-Agent: FRITZ!OS Content-Length: 0 2017-02-13 12:31:06.845 - IN: my=(null) peer=192.168.178.45 port=52906 TCP, sipiface=none: (null) 2017-02-13 12:31:06.845 - OUT: my=(null) peer=192.168.178.45 port=52906 TCP, sipiface=none tcclass=sip, netmark=0: SIP/2.0 400 Illegal request line From: <sip:missing> To: <sip:missing>;tag=badrequest User-Agent: FRITZ!OS Content-Length: 0 2017-02-13 12:31:06.846 - IN: my=(null) peer=192.168.178.45 port=52906 TCP, sipiface=none: (null) 2017-02-13 12:31:06.847 - OUT: my=(null) peer=192.168.178.45 port=52906 TCP, sipiface=none tcclass=sip, netmark=0: SIP/2.0 400 Illegal request line From: <sip:missing> To: <sip:missing>;tag=badrequest User-Agent: FRITZ!OS Content-Length: 0 ##### END SECTION sip Irgendeine Idee dazu? Vielen Dank nochmal!
Auch ohne Cisco-Telefon an der FRITZ!Box rate ich einfach mal weiter. Der Port gilt ja nur für die Kommunikation vom Telefon zur FRITZ!Box - da muß ja nur der Zielport in der FRITZ!Box fest sein, während der Absenderport im Telefon beliebig sein kann. Das ist nicht mit einer Konversation zu verwechseln, die "unangefordert" von der FRITZ!Box zum Telefon erfolgt, um dieses z.B. über einen eingehenden Anruf zu informieren. Das erfolgt dann selbstverständlich an den Port, auf dem das Telefon seinerseits "lauscht" und welcher das ist, steht wieder im REGISTER-Request. Das kann ein fester Port sein oder auch ein dynamischer ... es liegt im Ermessen des Clients und solange sich zwischen SIP-Server und SIP-Client keine weitere Firewall oder eine zusätzliche Adressumsetzung (NAT) befindet, interessiert das auch nicht, wenn es irgendein x-beliebiger Port ist (das ist nur dann eben unangenehm, wenn man den "freigeben" müßte und nicht wüßte, welcher es ist oder wird). Schaut man sich das REGISTER weiter oben an, verwendet das Telefon offensichtlich auch in der "Gegenrichtung" diesen Port: Code: Contact: <sip:[email protected]:52906;transport=tcp>;+sip. instance="<urn:uuid:00000000-0000-0000-0000-001c58f9c4f0>";+u.sip!devicename.ccm.cisco.com="SE P001C58F9C4F0";+u.sip!model.ccm.cisco.com="30018" Das ist ja die "Kontaktadresse", unter der die FRITZ!Box ihrerseits versuchen würde, mit dem Telefon in Verbindung zu treten. Auch bei der Verwendung von TCP wird ja normalerweise keine "ständige Verbindung" zwischen SIP-Server und SIP-Client aufrecht erhalten. Wobei hier wohl noch ein anderes Problem auftritt ... wenn das tatsächlich das komplette Protokoll ist in #17, dann sieht das ja fast so aus, als ob da "leere" SIP-Pakete kämen und offenbar bezieht der "voipd" dann die Informationen zum Absender aus dem TCP-Paket (Adresse und Port), aber die zur eigenen lokalen Adresse aus dem Inhalt - nicht ganz überraschend, wenn man bedenlt, daß so ein Interface ja auch mehrere Adressen haben kann und der "voipd" wohl neben dem eigentlichen Paket nur noch einen "hint" mit auf den Weg bekommt, auf welchem Interface das Paket nun hereinkam, damit ggf. zusätzliche Beschränkungen (z.B. "kein Zugriff aus dem Internet") durchgesetzt werden können. Fehlt jetzt der Inhalt (woran das genau liegt, wird wohl nur der Paketmitschnitt offenlegen können), funktioniert offenbar nicht einmal mehr das Protokollieren. Die Konfiguration davor habe ich mir allerdings gar nicht erst angesehen ... das gehört in vernünftige Tags und braucht (bzw. behält) dann auch eine Formatierung, bei der man etwas lesen kann. Am ehesten würde ich erwarten, daß man bei den Cisco-Telefonen mit Änderungen an der XML-Sektion "<sipCallFeatures>" eine Änderung an den "Supported"-Headern herbeiführen könnte ... aber nur als Idee verstehen und nicht als Wissen, testen kann ich es schon gar nicht. Bliebe halt noch die Frage, was das für merkwürdige "leere" Pakete sind und ob das nicht nur unvollständige Kommunikation zwischen FRITZ!Box und Telefon (nach dem 3-Wege-Handshake des TCP-Protokolls) ist. Ob das jetzt durch Timeout oder durch ein echtes FIN-Paket beendet wird, kann nur ein Mitschnitt zeigen.
Vielen Dank für die Mühe. Ich habe aber die Lösung jetzt offenbar gefunden. In der Cisco sep.cnf.xml gibt es eine Einstellung für das zu verwendende Protokoll, also TCP oder UDP. "2" steht für UDPund "1" ist TCP. Der Wert stand bei mir auf 1, ich habe ihn einfach auf 2 geändert und nun registriert sich das Telefon wieder an der Fritz Box. Diesen Eintrag suchen und den Wert auf 2 setzen: <transportLayerProtocol>2</transportLayerProtocol> Ich habe zwar noch nicht alles durchgetestet aber die Grundfunktion "telefonieren" in beide Richtungen funktioniert. Warum das nun vorher auch mit TCP geklappt hat und jetzt nicht mehr, bleibt erst mal das Geheimnis von AVM. Egal, Hauptsache das Telefon registriert sich wieder. In der Hoffnung das es bei anderen Betroffenen auch hilft. Gruß und viel Erfolg.
Hallo @PeterPan Sorry, tut mir leid. Das ist vielleicht falsch rübergekommen. Es sollte kein Vorwurf etc. sein. Alles gut ! Wie schon @jimpansen geschrieben hat, es ist super dass sich noch jemand Gedanken um das Problem macht und Helfen möchte ! Ich habe mich vor vielen Jahren mit der Materie Cisco an FB mit SIP lange beschäftigt aber es gibt halt immer noch Bezeichnungen und Fachausdrücke die ich nicht drauf habe! Man lernt halt einfach nie aus! ;-))) Ich habe den Eintrag „transportLayerProtocol“ in meiner SEP gerade nachgesehen. Bei mir steht das <transportLayerProtocol>4</transportLayerProtocol> drin !! Auf 4 nicht auf 1 oder 2 !! Warum ? keine Ahnung ?? Was bedeutet 4 ?? @jimpansen hast Du auch das Passwort wie oben im Beitrag geschrieben verlängert / geändert, damit es jetzt läuft ?? Grüße PS: Ich werde das ganze in den nächsten Tagen mal Testen !