[Problem] Cisco 7961 wählt seltsam

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
E

Edelschwein

Neuer User
Mitglied seit
19 Mai 2020
Beiträge
10
Punkte für Reaktionen
0
Punkte
1
Guten Abend,
ich habe inzwischen die Richtige Firmware auf das Gerät drauf geflasht und jetzt habe ich das Problem, dass ich (wahrscheinlich in der Konfigurations XML) was falsch eingestellt habe, denn nach einer Zeit beginnt das Telefon sich erneut zu registrieren und wenn es registriert ist, dann kann ich keine Nummer wählen (nur Schnellauswahl) weil er wahrscheinlich irgendwas vor die Nummer vorsetzt.

Ich habe diese: https://ctx4tom.wordpress.com/2014/03/16/ bzw. diese https://ctx4tom.wordpress.com/2016/09/17/cisco-ip-phone-an-fritzbox-teil-2-fritzbox-konfigurieren/ anleitung benutzt

Kann mir wer helfen?

Danke im Voraus
 
Ich deute deine Links so, dass du eine SIP-FIrmware und eine FritzBox verwendest. Modellbezeichnungen und Versionsnummer zu wissen wäre gut.

Erste Vermutung: Das Telefon muss sich regelmäßig bei der FritzBox melden, quasi eine Art HeartBeat-Signal. Die Standardwerte aus diversen Anleitungen im Netz sind zumindest für meine FB7530 viel zu groß, diese hier sind bei mir stabil:

Code: 
<sipProfile>
[...]
     <sipStack>
         <sipInviteRetx>6</sipInviteRetx>
         <sipRetx>10</sipRetx>
         <timerInviteExpires>60</timerInviteExpires>    <!--dieser-->
         <timerRegisterExpires>60</timerRegisterExpires>   <!--und dieser-->
         <timerRegisterDelta>5</timerRegisterDelta>   <!--und dieser-->
         <timerKeepAliveExpires>60</timerKeepAliveExpires>   <!--und dieser-->
         <timerSubscribeExpires>60</timerSubscribeExpires>   <!--und dieser-->
         <timerSubscribeDelta>5</timerSubscribeDelta>   <!--und dieser-->
         <timerT1>500</timerT1>   <!--und dieser-->
         <timerT2>4000</timerT2>   <!--und dieser-->
         <maxRedirects>70</maxRedirects>
         <remotePartyID>false</remotePartyID>
         <userInfo>None</userInfo>
      </sipStack>
</sipProfile>
 
Moinsen


terterter schrieb:
<timerRegisterExpires>60</timerRegisterExpires>
Zum Vergrößern anklicken....
Nur zur Information.
Wenn das Telefon 60 Sekunden anfragt, ist das Mindeste was die FRITZ!Box erlaubt 300 Sekunden.
Es ist nämlich so, dass der Server das letzte Wort dazu hat.
Beispiel
Sip-Klient Linphone beantragt 60s, FRITZ!Box genehmigt 300s...
Code: 
2020-06-03 11:38:47.400 - IN: my=192.168.188.1%12:5060 peer=192.168.188.21 port=5060 UDP, sipiface=none:
REGISTER sip:fritz.box 2.0
Via: SIP/2.0/UDP 192.168.188.21:5060;branch=<hash>;rport
From: <sip:[email protected]>;tag=<hash>
To: <sip:[email protected]>
Call-ID: <hash>
CSeq: 21 REGISTER
Contact: <sip:[email protected];transport=udp>;+sip.instance="<urn:uuid:<hash>>"
Authorization: Digest username="koyaanisqatsi", realm="fritz.box", nonce="<hash>", uri="sip:fritz.box", response="<hash>"
Max-Forwards: 70
Supported: replaces
Supported: outbound
Expires: 60
User-Agent: Linphone/3.12.0 (belle-sip/1.6.3)
Accept: application/sdp, text/plain, application/vnd.gsma.rcs-ft-http+xml
Content-Length: 0



2020-06-03 11:38:47.404 - OUT: my=192.168.188.1%12:5060 peer=192.168.188.21 port=5060 UDP, sipiface=none tcclass=sip_internet, netmark=0:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.188.21:5060;branch=<hash>;rport=5060
From: <sip:[email protected]>;tag=<hash>
To: <sip:[email protected]>;tag=<hash>
Call-ID: <hash>
CSeq: 21 REGISTER
Contact: <sip:[email protected];transport=udp>;+sip.instance="<urn:uuid:<hash>>";expires=300
User-Agent: AVM FRITZ!Box 7590 (UI) 154.07.19 (May 26 2020)
Supported: 100rel,replaces,timer
Allow-Events: telephone-event,refer,reg
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0
( SIP Log aus den erweiterten Support-Daten )
Das 300s Expiry siehst du in der Antwort unter: Contact:
Wenn der Klient sich nicht daran hält, und sich trotzdem alle 60s registriert, ist das ein Fehler.
Deswegen empfehle ich mind. 300s.
Hab aber auch Klienten die mit 1800s Antrag ankommen und die auch bekommen.
 
Zuletzt bearbeitet:
koyaanisqatsi schrieb:
Wenn das Telefon 60 Sekunden anfragt, ist das Mindeste was die FRITZ!Box erlaubt 300 Sekunden.
Zum Vergrößern anklicken....
Die Anfrage der 60s und Beantwortung mit 300s kann ich durch mein SIP-Log nur halb bestätigen: Die 60s werden in der Anfrage gar nicht mitgeschickt, aber die 300s stehen tatsächlich in der Antwort:


Code: 
2020-06-11 01:18:22.736 - IN: my=192.168.2.254%11:5060 peer=192.168.2.100 port=49436 UDP, sipiface=none:
REGISTER sip:192.168.2.254 2.0
Via: SIP/2.0/UDP 192.168.2.100:5060;branch=<hash>
From: <sip:[email protected]>;tag=<hash>
To: <sip:[email protected]>
Call-ID: <hash>@192.168.2.100
CSeq: 550 REGISTER
Contact: <sip:[email protected]:5060;transport=udp>;+sip.instance="<urn:uuid:<hash>>";+u.sip!devicename.ccm.cisco.com="SEP<MAC>";+u.sip!model.ccm.cisco.com="435"
Authorization: Digest username="Cisco7945G", realm="fritz.box", nonce="<hash>", uri="sip:192.168.2.254", response="<hash>", algorithm=md5
Max-Forwards: 70
Date: Wed, 10 Jun 2020 23:18:22 GMT
User-Agent: Cisco-CP7945G/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


2020-06-11 01:18:22.737 - OUT: my=192.168.2.254%11:5060 peer=192.168.2.100 port=5060 UDP, sipiface=none tcclass=sip_internet, netmark=0:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.100:5060;branch=<hash>
From: <sip:[email protected]>;tag=<hash>
To: <sip:[email protected]>;tag=<hash>
Call-ID: <hash>@192.168.2.100
CSeq: 550 REGISTER
Contact: <sip:[email protected]:5060;transport=udp>;+sip.instance="<urn:uuid:<hash>>";+u.sip!devicename.ccm.cisco.com="SEP<MAC>";+u.sip!model.ccm.cisco.com="435";expires=300


Meine "zu kleinen" Werte sind übrigens empirisch entstanden aus der Beobachtung, dass mein Telefon mit den normalen Werten regelmäßig rebootet, in der Registrierung hängenbleibt (versucht es dann alle paar Minuten erneut) oder sich ganz aufhängt (nur ein physischer Powercycle hilft dann noch). Da ich meine Werte durch Trial&Error gefunden habe kann es gut sein, dass nur einer der Werte entscheidend ist und alle anderen in der Tat fehlergenerieren sind. Falls Du Ideen dazu hast freue ich mich darauf sie zu lesen!
 
Zuletzt bearbeitet:
terterter schrieb:
Die 60s werden in der Anfrage gar nicht mitgeschickt […] falls Du Ideen dazu hast […]
Zum Vergrößern anklicken....
Spannend. Die Frage ist dann, was der Parameter timerRegisterExpires überhaupt bewirkt: Wann genau schickt Dein Cisco das erste re-REGISTER? Und setze bei dem Test bitte mal timerKeepAliveExpires sehr lang, damit nicht das ein re-REGISTER auslöst. Die nächste Frage ist nämlich, was timerKeepAliveExpires genau macht: OPTIONS, re-REGISTER oder CRLFCRLF.
 
sonyKatze schrieb:
Spannend. Die Frage ist dann, was der Parameter timerRegisterExpires überhaupt bewirkt: Wann genau schickt Dein Cisco das erste re-REGISTER?
Zum Vergrößern anklicken....
Gute Frage. Wie kann ich das am einfachsten herausbekommen, ohne dauerhaft Wireshark mitlaufen zu lassen?

Ich habe das betreffende Telefon übrigens seit vorgestern testweise wieder mit den Standardwerten laufen.
Code: 
<sipInviteRetx>6</sipInviteRetx>
<sipRetx>10</sipRetx>
<timerInviteExpires>180</timerInviteExpires>
<timerRegisterExpires>3600</timerRegisterExpires>
<timerRegisterDelta>5</timerRegisterDelta>
<timerKeepAliveExpires>120</timerKeepAliveExpires>
<timerSubscribeExpires>120</timerSubscribeExpires>
<timerSubscribeDelta>5</timerSubscribeDelta>
<timerT1>500</timerT1>
<timerT2>4000</timerT2>

Das ursprüngliche Troubleshooten war übrigens nicht ganz einfach, weil das Telefon nur alle 2-7 Tage Probleme machte. Daher war ich mit den kleinen Timer-Werten zufrieden, ohne die tatsächliche Problemursache identifiziert zu haben.
 
terterter schrieb:
Die 60s werden in der Anfrage gar nicht mitgeschickt, aber die 300s stehen tatsächlich in der Antwort
Zum Vergrößern anklicken....
Hm, vermutlich aber doch, denn dein Post enthält nur die Hälfte der Kommunikation.
Bei einen sich zu authorisierenden REGISTER bekommt der anfragende Klient erstmal ein 401 - Unauthorized.
Welches aber ein NONCE enthält, dass der Klient (richtig) beantworten muss.
Also schau mal nach was vor dem 401 in der ersten REGISTER Anfrage steht ;)
 
koyaanisqatsi schrieb:
Hm, vermutlich aber doch,
Zum Vergrößern anklicken....
Leider nein (-:
Ich habe auch das komplette SIP-Log nach "expir" durchsucht und das erwartete "Expires: <wert>" nur in Zusammenhang mit INVITE, PUBLISH und REFER gefunden.

koyaanisqatsi schrieb:
[...] denn dein Post enthält nur die Hälfte der Kommunikation.
Bei einen sich zu authorisierenden REGISTER bekommt der anfragende Klient erstmal ein 401 - Unauthorized.
Zum Vergrößern anklicken....
Das ist richtig. Manchmal schickt das Telefon sogar mehrere Anfragen ohne Authorization-Datensatz hintereinander, die entsprechend alle mit 401 beantwortet werden. Weiß aber nicht, warum es mehrere sendet.

Vollständige Registering-Sequenz aus meinem Fritzbox-Log (nur <hash> und SEPMAC geändert):

Code: 
2020-06-12 18:42:41.505 - IN: my=192.168.2.254%11:5060 peer=192.168.2.100 port=50049 UDP, sipiface=none:
REGISTER sip:192.168.2.254 2.0
Via: SIP/2.0/UDP 192.168.2.100:5060;branch=<hash>
From: <sip:[email protected]>;tag=<hash>
To: <sip:[email protected]>
Call-ID: <hash>@192.168.2.100
CSeq: 181 REGISTER
Contact: <sip:[email protected]:5060;transport=udp>;+sip.instance="<urn:uuid:<hash>>";+u.sip!devicename.ccm.cisco.com="SEPMAC";+u.sip!model.ccm.cisco.com="435"
Max-Forwards: 70
Date: Fri, 12 Jun 2020 16:42:41 GMT
User-Agent: Cisco-CP7945G/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-cisc
2020-06-12 18:42:41.506 - OUT: my=192.168.2.254%11:5060 peer=192.168.2.100 port=5060 UDP, sipiface=none tcclass=sip_internet, netmark=0:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.2.100:5060;branch=<hash>
From: <sip:[email protected]>;tag=<hash>
To: <sip:[email protected]>;tag=<hash>
Call-ID: <hash>@192.168.2.100
CSeq: 181 REGISTER
WWW-Authenticate: Digest realm="fritz.box", nonce="<hash>"
User-Agent: FRITZ!OS
Content-Length: 0



2020-06-12 18:42:41.515 - IN: my=192.168.2.254%11:5060 peer=192.168.2.100 port=50049 UDP, sipiface=none:
REGISTER sip:192.168.2.254 2.0
Via: SIP/2.0/UDP 192.168.2.100:5060;branch=<hash>
From: <sip:[email protected]>;tag=<hash>
To: <sip:[email protected]>
Call-ID: <hash>@192.168.2.100
CSeq: 182 REGISTER
Contact: <sip:[email protected]:5060;transport=udp>;+sip.instance="<urn:uuid:<hash>>";+u.sip!devicename.ccm.cisco.com="SEPMAC";+u.sip!model.ccm.cisco.com="435"
Authorization: Digest username="Cisco7945G", realm="fritz.box", nonce="<hash>", uri="sip:192.168.2.254", response="<hash>", algorithm=md5
Max-Forwards: 70
Date: Fri, 12 Jun 2020 16:42:41 GMT
User-Agent: Cisco-CP7945G/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
2020-06-12 18:42:41.517 - OUT: my=192.168.2.254%11:5060 peer=192.168.2.100 port=5060 UDP, sipiface=none tcclass=sip_internet, netmark=0:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.100:5060;branch=<hash>
From: <sip:[email protected]>;tag=<hash>
To: <sip:[email protected]>;tag=<hash>
Call-ID: <hash>@192.168.2.100
CSeq: 182 REGISTER
Contact: <sip:[email protected]:5060;transport=udp>;+sip.instance="<urn:uuid:<hash>>";+u.sip!devicename.ccm.cisco.com="SEPMAC";+u.sip!model.ccm.cisco.com="435";expires=300
User-Agent: AVM FRITZ!Box 7530 164.07.14 (Jul  8 2019)
Supported: 100rel,replaces,timer
Allow-Events: telephone-event,refer,reg
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0
 
Ehrlich, ich krieg bei der (SIP) Konversation nicht gebacken, warum die FRITZ!Box den Contact: des Cisco 1:1 übernimmt.
Denn wenn das Cisco die IP *.100 hat, müsste es ja wohl die [email protected] sein.
...und wieso ist das Cisco der Meinung, die 620 ( [email protected] ) als Contact: zu offerieren?
 
Zuletzt bearbeitet:
koyaanisqatsi schrieb:
Denn wenn das Cisco die IP *.100 hat, müsste es ja woh die [email protected] sein.
...und wieso ist das Cisco der Meinung, die 620 ( [email protected] ) als Contact: zu offerieren?
Zum Vergrößern anklicken....
Hängt vermutlich damit zusammen, dass ich nicht der Standard-Empfehlung "Telefonbenutzername gleich interne Rufnummer" folge. Sinngemäß aus meiner SEPMAC:
  • <name>: NICHT die interne Nummer, sondern aus FritzBox»Telefoniegeräte»(dieses Telefon) Bearbeiten»Anmeldedaten»Benutzername (bei mir "Cisco7945G")
  • <displayName>: 620 (weil FB **620 anzeigt)
  • <contact>: auch 620
  • <authName>: auch Benutzername ("Cisco7645G")
  • <authPassword>: FritzBox»Telefoniegeräte»(dieses Telefon) Bearbeiten»Anmeldedaten»Kennwort (bei mir sinngemäß "Abcdefg123456")

Falls du denkst dass das was ändert kann ich gerne einmal ausprobieren, FB-Benutzername, <name> und <authName> allesamt auch auf 620 zu setzen,
 
Nee, ich denke dass der Contact: nicht 620 sein darf.
Also bloss nichts auf 620 ändern sondern auf den VoiP-Benutzer-Anmeldenamem des IP-Telefon-Registrars in der FRITZ!Box.
Schau dir dazu mal Post #3 an.
 
Ich sehe den Unterschied zwischen deinem und meinem Log. Kann ihn aber auch nicht erklären. Vielleicht sind unterschiedliche Softwareversionen die Erklärung? Hab eine FB 7530 auf v7.14 und dieses Telefon läuft auf SIP45.9-4-2SR3-1S.


koyaanisqatsi schrieb:
sondern auf den VoiP-Benutzer-Anmeldenamem des IP-Telefon-Registrars in der FRITZ!Box.
Zum Vergrößern anklicken....
So hab ich das, anders könnte sich das Telefon doch gar ncht bei der FB anmelden, oder?
1592035088428.png

1592035124582.png

1592035164826.png
[Edit Novize: Riesenbilder entsprechend der Forumsregeln auf Vorschau verkleinert]
 
Zuletzt bearbeitet von einem Moderator:
Das kommt eher vom Cisco.
Der Kanditat wird laut Post #11 <contact> sein und da statt 620 mal Cisco7495G rein.
Ich nutze 7560 mit 7.12 und 7590 mit 7.19 Inhaus Version.
 
Danke für die Idee!
  • Meine Tests bestätigen dass du mit der Zuordnung zwischen der Zeile im Log und <contact> in der SEPMAC Recht hast.
  • Allerdings auch, dass es in meinem Setup für die Funktion anscheinend egal ist, was in diesem Eintrag steht.
  • Das Telefon sendete bisher nie seinen eigenen expires-Header.

Details:
Habe in meiner SEP<MAC> folgendes gesetzt (Fritzbox-Config und alles andere in der SEPMAC unverändert):
Code: 
<contact>5678</contact>
Aus- und eingehende Anrufe funktionieren.

Ausschnitt des SIP-Logs vom REGISTER-Teil:
Code: 
2020-06-13 21:56:30.886 - IN: my=192.168.2.254%11:5060 peer=192.168.2.100 port=51336 UDP, sipiface=none:
REGISTER sip:192.168.2.254 2.0
Via: SIP/2.0/UDP 192.168.2.100:5060;branch=<hash>
From: <sip:[email protected]>;tag=<hash>
To: <sip:[email protected]>
Call-ID: <hash>@192.168.2.100
CSeq: 102 REGISTER
Contact: <sip:[email protected]:5060;transport=udp>;+sip.instance="<urn:uuid:<hash>>";+u.sip!devicename.ccm.cisco.com="SEPMAC";+u.sip!model.ccm.cisco.com="435"
Authorization: Digest username="Cisco7945G", realm="fritz.box", nonce="<hash>", uri="sip:192.168.2.254", response="<hash>", algorithm=md5
Max-Forwards: 70
Mit anderen Worten: Ja, <contact> taucht in Contact: <sip:[email protected]:5060;transport=udp> auf.


Dann Änderung der SEPMAC zu:
Code: 
<contact>CISCO7945G</contact>
Aus- und eingehende Anrufe funktionieren.

Ausschnitt des SIP-Logs vom REGISTER-Teil, wieder ohne dass das Telefon ein Expires: sendet:
Code: 
2020-06-13 22:14:28.315 - IN: my=192.168.2.254%11:5060 peer=192.168.2.100 port=52931 UDP, sipiface=none:
REGISTER sip:192.168.2.254 2.0
Via: SIP/2.0/UDP 192.168.2.100:5060;branch=<hash>
From: <sip:[email protected]>;tag=<hash>
To: <sip:[email protected]>
Call-ID: <hash>@192.168.2.100
CSeq: 101 REGISTER
Contact: <sip:[email protected]:5060;transport=udp>;+sip.instance="<urn:uuid:<hash>>";+u.sip!devicename.ccm.cisco.com="SEPMAC";+u.sip!model.ccm.cisco.com="435"
Max-Forwards: 70
Date: Sat, 13 Jun 2020 20:14:28 GMT
User-Agent: Cisco-CP7945G/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:
2020-06-13 22:14:28.316 - OUT: my=192.168.2.254%11:5060 peer=192.168.2.100 port=5060 UDP, sipiface=none tcclass=sip_internet, netmark=0:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.2.100:5060;branch=<hash>
From: <sip:[email protected]>;tag=<hash>
To: <sip:[email protected]>;tag=<hash>
Call-ID: <hash>@192.168.2.100
CSeq: 101 REGISTER
WWW-Authenticate: Digest realm="fritz.box", nonce="<hash>"
User-Agent: FRITZ!OS
Content-Length: 0



2020-06-13 22:14:28.329 - IN: my=192.168.2.254%11:5060 peer=192.168.2.100 port=52931 UDP, sipiface=none:
REGISTER sip:192.168.2.254 2.0
Via: SIP/2.0/UDP 192.168.2.100:5060;branch=<hash>
From: <sip:[email protected]>;tag=<hash>
To: <sip:[email protected]>
Call-ID: <hash>@192.168.2.100
CSeq: 102 REGISTER
Contact: <sip:[email protected]:5060;transport=udp>;+sip.instance="<urn:uuid:<hash>>";+u.sip!devicename.ccm.cisco.com="SEPMAC";+u.sip!model.ccm.cisco.com="435"
Authorization: Digest username="Cisco7945G", realm="fritz.box", nonce="<hash>", uri="sip:192.168.2.254", response="<hash>", algorithm=md5
Max-Forwards: 70
Date: Sat, 13 Jun 2020 20:14:28 GMT
User-Agent: Cisco-CP7945G/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-ser
2020-06-13 22:14:28.331 - OUT: my=192.168.2.254%11:5060 peer=192.168.2.100 port=5060 UDP, sipiface=none tcclass=sip_internet, netmark=0:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.100:5060;branch=<hash>
From: <sip:[email protected]>;tag=<hash>
To: <sip:[email protected]>;tag=2F872544272D1BDB
Call-ID: <hash>@192.168.2.100
CSeq: 102 REGISTER
Contact: <sip:[email protected]:5060;transport=udp>;+sip.instance="<urn:uuid:<hash>>";+u.sip!devicename.ccm.cisco.com="SEPMAC";+u.sip!model.ccm.cisco.com="435";expires=300
User-Agent: AVM FRITZ!Box 7530 164.07.14 (Jul  8 2019)
Supported: 100rel,replaces,timer
Allow-Events: telephone-event,refer,reg
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0



Ich habe dann in Hinblick auf die LABEL-Theorie (siehe Link weiter unten) testweise noch folgendes im Telefon gesetzt, wieder ohne etwas an der Config meiner Fritzbox zu ändern:
Code: 
<displayName>1234</displayName>
<contact>5678</contact>
Das Telefon registriert sich problemlos; ausgehende Telefonate funktionieren, eingehende werden aber nicht signalisiert.

SIP-Log des REGISTER-Teils:
Code: 
2020-06-13 21:38:13.034 - IN: my=192.168.2.254%11:5060 peer=192.168.2.100 port=50183 UDP, sipiface=none:
REGISTER sip:192.168.2.254 2.0
Via: SIP/2.0/UDP 192.168.2.100:5060;branch=<hash>
From: <sip:[email protected]>;tag=<hash>
To: <sip:[email protected]>
Call-ID: <hash>@192.168.2.100
CSeq: 101 REGISTER
Contact: <sip:[email protected]:5060;transport=udp>;+sip.instance="<urn:uuid:<hash>>";+u.sip!devicename.ccm.cisco.com="SEPMAC";+u.sip!model.ccm.cisco.com="435"
Max-Forwards: 70
Date: Sat, 13 Jun 2020 19:38:13 GMT
User-Agent: Cisco-CP7945G/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-cis
2020-06-13 21:38:13.035 - OUT: my=192.168.2.254%11:5060 peer=192.168.2.100 port=5060 UDP, sipiface=none tcclass=sip_internet, netmark=0:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.2.100:5060;branch=<hash>
From: <sip:[email protected]>;tag=<hash>
To: <sip:[email protected]>;tag=B13E9CEBF2FBFE7A
Call-ID: <hash>@192.168.2.100
CSeq: 101 REGISTER
WWW-Authenticate: Digest realm="fritz.box", nonce="<hash>"
User-Agent: FRITZ!OS
Content-Length: 0



2020-06-13 21:38:13.048 - IN: my=192.168.2.254%11:5060 peer=192.168.2.100 port=50183 UDP, sipiface=none:
REGISTER sip:192.168.2.254 2.0
Via: SIP/2.0/UDP 192.168.2.100:5060;branch=<hash>
From: <sip:[email protected]>;tag=<hash>
To: <sip:[email protected]>
Call-ID: <hash>@192.168.2.100
CSeq: 102 REGISTER
Contact: <sip:[email protected]:5060;transport=udp>;+sip.instance="<urn:uuid:<hash>>";+u.sip!devicename.ccm.cisco.com="SEPMAC";+u.sip!model.ccm.cisco.com="435"
Authorization: Digest username="Cisco7945G", realm="fritz.box", nonce="<hash>", uri="sip:192.168.2.254", response="<hash>", algorithm=md5
Max-Forwards: 70
Date: Sat, 13 Jun 2020 19:38:13 GMT
User-Agent: Cisco-CP7945G/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-serviceur
2020-06-13 21:38:13.050 - OUT: my=192.168.2.254%11:5060 peer=192.168.2.100 port=5060 UDP, sipiface=none tcclass=sip_internet, netmark=0:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.100:5060;branch=<hash>
From: <sip:[email protected]>;tag=<hash>
To: <sip:[email protected]>;tag=<hash>
Call-ID: <hash>@192.168.2.100
CSeq: 102 REGISTER
Contact: <sip:[email protected]:5060;transport=udp>;+sip.instance="<urn:uuid:<hash>>";+u.sip!devicename.ccm.cisco.com="SEPMAC";+u.sip!model.ccm.cisco.com="435";expires=300
User-Agent: AVM FRITZ!Box 7530 164.07.14 (Jul  8 2019)
Supported: 100rel,replaces,timer
Allow-Events: telephone-event,refer,reg
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0


Dass das Telefon seinen Expires-Wunsch sendet, habe ich nicht hinbekommen. Habe auch einmal die gesamte Hardware power-gecycled, die dann erste Registrierung lief gleich ab.


Ich finde leider keine richtige Dokumentation für alles was mit der SEPMac.cnf.xml zu tun hat, auch nicht zum <contact>. Als Anregung habe ich https://community.cisco.com/t5/small-business-routers/sep-cnf-xml-parameters/td-p/3002478 gefunden, das Posting deutet meiner Meinung nach darauf hin, dass <displayName> und <contact> einfach nur interne Labels des Telefons sind. Ist aber wie oben gezeigt nicht so.
 
Zuletzt bearbeitet:
Siehste mal, eventuell ist es auch OK, wenn <contact> einfach leer bleibt?
Ein inhaltsloses XML-Element sieht so aus...
HTML: 
<contact/>
Auf jedenfall nutzt die FRITZ!Box den Contact: Header um das Cisco zu erreichen.
Steht da der falsche Benutzername drinne, klingelts/signalisiert es auch keine eingehende Anrufe.

Display Name
HTML: 
<displayName>1234</displayName>
Hat offensichtlich ( SIP Log ) nichts mit der CallerID* zu tun.
Und wird vom Cisco nur für die Displayanzeige genutzt?
...da kannste also reinschreiben was du willst ;)


* Format: "Firma/Title Vorname Nachname"<sip:Benutzername@Registrar:Port;Option=Inhalt>
Header: From: To: P-Asserted-Identity: P-Preferred-Identity:
 
Zuletzt bearbeitet:
terterter schrieb:
Wie kann ich […] am einfachsten herausbekommen [,was timerRegisterExpires bewirkt], ohne dauerhaft Wireshark mitlaufen zu lassen?
Zum Vergrößern anklicken....
Du musst Wireshark nur bis zum nächsten re-REGISTER mitlaufen lassen, also im Falle einer FRITZ!Box keine 10 Minuten.
 
sonyKatze schrieb:
Du musst Wireshark nur bis zum nächsten re-REGISTER mitlaufen lassen, also im Falle einer FRITZ!Box keine 10 Minuten.
Zum Vergrößern anklicken....
Hatte gehofft dass die Fritzbox vielleicht irgendeine Logging-Funktionalität hat die das auch kann.
Also Wireshark. Danke für den Hinweis mit den zehn Minuten!

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

koyaanisqatsi schrieb:
HTML: 
<displayName>1234</displayName>
Hat offensichtlich ( SIP Log ) nichts mit der CallerID* zu tun.
Und wird vom Cisco nur für die Displayanzeige genutzt?
Zum Vergrößern anklicken....
Nein, im Cisco taucht der Wert auch nirgendswo auf. Ist vielleicht irgendein Legacy-Wert oder nur bei einigen aktuelle Modellen verwendet und bei meinem nicht.

koyaanisqatsi schrieb:
...da kannste also reinschreiben was du willst ;)
Zum Vergrößern anklicken....
In meinem Fall: Ja, absolut (-:


Das Telefon läuft übrigens seit Samstag mit den hohen Timer-Werten stabil. Ich lasse sie erstmal so.
 
Zuletzt bearbeitet von einem Moderator:
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 583 (Mitglieder: 23, Gäste: 560)

Neueste Beiträge

Statistik des Forums

Themen
246,308
Beiträge
2,249,817
Mitglieder
373,915
Neuestes Mitglied
sunburstc
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück