SIP Seeding Peer - wieso so oft hintereinander?

[Guard-X]

Im Verbose Modus tauchen immer diese Meldungen auf:

-- SIP Seeding peer from astdb: '92389' at 92389@<IP>:2051 for 3600
-- SIP Seeding peer from astdb: '92389' at 92389@<IP>:2051 for 3600
-- SIP Seeding peer from astdb: '92389' at 92389@<IP>:2051 for 3600
-- SIP Seeding peer from astdb: '92389' at 92389@<IP>:2051 for 3600
-- SIP Seeding peer from astdb: '92389' at 92389@<IP>:2051 for 3600
-- SIP Seeding peer from astdb: '92389' at 92389@<IP>:2051 for 3600
-- SIP Seeding peer from astdb: '92389' at 92389@<IP>:2051 for 3600
-- SIP Seeding peer from astdb: '92389' at 92389@<IP>:2051 for 3600

Ein bischen merkwürdig ist, das jede Rufnummmer so oft nacheinander auftaucht. Eine Registrierung würde doch reichen, oder?

Haben die SNOM 360 da ein Problem?

 

[betateilchen]

Mach mal ein "show database" und dann lösche den dort vorhandenen Registrierungs-Eintrag für die Nummer des sip-peers. Danach ist dann Ruhe. Sicherheitshalber kannst Du auch das Telefon neu booten.

Sowas passiert meistens nach einem Restart des Asterisk. Ob es sich dabei um ein Snom-spezifisches Problem handelt, kann ich Dir nicht beantworten - ich habe das aber auch schon mit anderen Geräten erlebt.

 

[Guard-X]

Dann müsste ich die ganze Datenbank ablöschen, das machen auf dem einen Server alle 220 Teilnehmer, auf dem anderen gerade erst neu installierten Server alle 40 Teilnehmer. Der wurde noch nie neugestartet!?

Vielleicht ein Problem mit Realtime?

 

[betateilchen]

Vielleicht ein Problem mit Realtime?

Ich arbeite auch mit Realtime - aber bei mir tritt diese Meldung nur sehr selten mal auf s.o.

Zeig doch mal den [general] Teil Deiner sip.conf.

 

[Guard-X]

Ich denke mal, das möchtest du sehen:

;rtcachefriends=yes
rtupdate=yes
;rtautoclear=yes
ignoreregexpire=yes

 

[Guard-X]

Das scheinen die anderen Clients (SmartNodes) auch zu machen.

Und zwar nur bei Realtime...

Bei mir kommen z.Zt. tausende Meldungen/h und ich habe Angst das es mir den Asterisk überfordert.

 

[betateilchen]

Ich denke mal, das möchtest du sehen:

Ersetze doch mal

;rtcachefriends=yes
rtupdate=yes
;rtautoclear=yes
ignoreregexpire=yes

durch

rtcachefriends=yes
rtautoclear=yes

Mich interessiert, ob Du die Meldungen dann immer noch bekommst.

 

[Guard-X]

Muss ich mal auf dem Testsystem versuchen, dann sind die SIP Clients nämlich nicht mehr Realtime.

Mit "rtcachefriends=yes" wird alles gecached und ein Reload lädt nicht immer alle Werte neu aus der Datenbank...

 

[betateilchen]

ich hatte mit rtcachefriends=yes noch nie Probleme mit nicht geladenen oder nicht aktuellen Daten :!:

 

[Maik]

Ich schon. Meine Erfahrung ist, dass bei rtcachefriends=yes die Daten nie upgedatet werden, wenn das Telefon dauerhaft angemeldet ist. Ich verwende allerdings auf diesem System eine nicht ganz aktuelle CVS-Version. Da wurde vor dem 1.2er Release noch irgendwas dran rumgebastelt. Ich kann jetzt aber leider nicht mehr genau sagen, was es war.

 

[Guard-X]

Hi Maik,

endlich mal jemand der mir zustimmt. Bei mir gibt es auch auf allen Servern Probleme mit diesem Eintrag. Habe noch keine Lösung gefunden...

Ihr erinnert Euch: http://www.ip-phone-forum.de/showthread.php?t=88808

Ist auch nicht so schlimm, ich hab es ja ausgeschaltet.

Aber das SIP Seeding stört mich ein wenig. Ach übrigens, wisst Ihr auch was Seeding auf deutsch heisst? Ich glaube mein Dictionary ist defekt

 

[betateilchen]

Meine Erfahrung ist, dass bei rtcachefriends=yes die Daten nie upgedatet werden, wenn das Telefon dauerhaft angemeldet ist.

Ich arbeite mit Asterisk 1.2.1 und meine Geräte sind permanent angemeldet. Sowohl neue Geräte als auch die angemeldeten Geräte sind - mit rtcachefriends=yes - immer aktuell. Erkennbar an den Timestamps, die in die Datenbanktabelle mit den SIP-peers geschrieben werden.

 

[Guard-X]

Sowohl neue Geräte als auch die angemeldeten Geräte sind - mit rtcachefriends=yes - immer aktuell. Erkennbar an den Timestamps, die in die Datenbanktabelle mit den SIP-peers geschrieben werden.

Ändere doch mal die Callgroup und die Pickupgroup bei 2 Teilnehmer von Wert X auf 63 und sage uns mal ob die Anrufübernahme funktioniert.

Wenn das funktioniert, schalte ich es sofort auf "yes" !

 

[betateilchen]

Ändere doch mal die Callgroup und die Pickupgroup bei 2 Teilnehmer von Wert X auf 63 und sage uns mal ob die Anrufübernahme funktioniert.

Wenn das funktioniert, schalte ich es sofort auf "yes" !

Ich habe keinen Verwendungszweck für Callgroup und Pickupgroup. Deshalb hab ich das auch gar nicht konfiguriert. Aber ich kann das bei Gelegenheit mal testen.

Aber die Frage, ob mit den von mir vorgeschlagenen Änderungen die seeding-Nachrichten verschwinden, hast Du immer noch nicht beantwortet.

 

[Guard-X]

Ich habe keinen Verwendungszweck für Callgroup und Pickupgroup. Deshalb hab ich das auch gar nicht konfiguriert. Aber ich kann das bei Gelegenheit mal testen.

Aber die Frage, ob mit den von mir vorgeschlagenen Änderungen die seeding-Nachrichten verschwinden, hast Du immer noch nicht beantwortet.

Das ist nicht so einfach, wie gesagt, wenn ich das auf den Produktiv Servern aktiviere, funktioniert die Hälfte vom Realtime Konstrukt nicht mehr. Werde das wahrscheinlich morgen ääh heute mal am Testsystem ausprobieren...

 

[VOIPdani]

Hallo!

Ich habe auch das Problem dass mein * ständig folgende Meldungen ausspuckt:

Jan 23 08:15:27 VERBOSE[5018] logger.c:     -- SIP Seeding peer from astdb: 'GrRe' at [email protected]:5060 for 120
Jan 23 08:15:27 VERBOSE[5018] logger.c:     -- Saved useragent "SJphone/1.60.289a (SJ Labs)" for peer GrRe
Jan 23 08:15:30 VERBOSE[5018] logger.c:     -- SIP Seeding peer from astdb: 'HaMa' at [email protected]:5060 for 120
Jan 23 08:15:30 VERBOSE[5018] logger.c:     -- Saved useragent "SJphone/1.60.289a (SJ Labs)" for peer HaMa
Jan 23 08:15:34 VERBOSE[5018] logger.c:     -- SIP Seeding peer from astdb: 'GmeJ' at [email protected]:5060 for 120
Jan 23 08:15:34 VERBOSE[5018] logger.c:     -- Saved useragent "SJphone/1.60.289a (SJ Labs)" for peer GmeJ
Jan 23 08:15:43 VERBOSE[5018] logger.c:     -- Saved useragent "SJphone/1.60.289a (SJ Labs)" for peer HofD
Jan 23 08:15:44 VERBOSE[5018] logger.c:     -- SIP Seeding peer from astdb: 'RiTa' at [email protected]:5060 for 120
Jan 23 08:15:44 VERBOSE[5018] logger.c:     -- Saved useragent "SJphone/1.60.289a (SJ Labs)" for peer RiTa
Jan 23 08:15:48 VERBOSE[5018] logger.c:     -- SIP Seeding peer from astdb: 'MitT' at [email protected]:5060 for 120
Jan 23 08:15:48 VERBOSE[5018] logger.c:     -- Saved useragent "SJphone/1.60.289a (SJ Labs)" for peer MitT
Jan 23 08:17:22 VERBOSE[5018] logger.c:     -- SIP Seeding peer from astdb: 'BS01' at [email protected]:5060 for 3600
Jan 23 08:17:22 VERBOSE[5018] logger.c:     -- Saved useragent "PolycomSoundStationIP-SSIP_4000-UA/1.4.1" for peer BS01
Jan 23 08:18:31 VERBOSE[5018] logger.c:     -- SIP Seeding peer from astdb: 'Fax1' at [email protected]:5060 for 3600
Jan 23 08:18:31 VERBOSE[5018] logger.c:     -- Saved useragent "Linksys/PAP2-2.0.12(LS)" for peer Fax1

Zum einen weiß ich nicht so recht wieso mein Asterisk das macht, zum anderen weiß ich nicht wie die ganzen User in die astdb reingekommen sind.

rtcachefriends=yes
rtautoclear=yes

Mich interessiert, ob Du die Meldungen dann immer noch bekommst.

Ich habe den general-Teil meiner sip.conf mal so angepasst, aber die Seeding-Meldungen werden trotzdem ausgegeben.

Was bedeuten diese Seeding-Meldungen eigentlich?

lg Dani

 

[Guard-X]

Hi Dani,

die Seeding Meldung kommt immer wenn sich ein Teilnehmer versucht zu registrieren. Bei SNOMs standarmäßig jede Stunde. Ich habe festgestellt, das SNOM Telefone sehr viele gelichzeitige Meldungen machen, Patton Gateways jeweils nur zwei.

Scheint aber kein Problem für den Server zu sein...

 

[VOIPdani]

Also eine Registrierung sieht bei mir wie folgt aus:

Jan 23 10:57:28 VERBOSE[5018] logger.c:     -- Registered SIP 'AscH' at 172.21.1.81 port 5060 expires 120
Jan 23 10:57:28 VERBOSE[5018] logger.c:     -- Saved useragent "SJphone/1.60.289a (SJ Labs)" for peer AscH

Ich verwende auch keine SNOMs sondern Softphones (SJPhone).

Aber wenn du sagts es sei kein Problem für den Server.....

 

[Guard-X]

Ich muss mich verbessern. Kommt auch, wenn ein Teilnehmer angewählt wird!

 

[VOIPdani]

Ich muss mich verbessern. Kommt auch, wenn ein Teilnehmer angewählt wird!

Ich habe das mal getestet:

Jan 25 08:03:28 WARNING[3324]: chan_zap.c:8162 zt_pri_error: 8 TEI remove TEI = 0
Jan 25 08:03:29 WARNING[3324]: chan_zap.c:8162 zt_pri_error: 8 TEI remove TEI = 0
    -- Zap/1-1 answered Zap/16-1
    -- Attempting native bridge of Zap/16-1 and Zap/1-1
    [B]-- Registered SIP 'FuKa' at 172.21.1.140 port 5060 expires 120
    -- Saved useragent "SJphone/1.60.289a (SJ Labs)" for peer FuKa[/B]
    -- Channel 0/1, span 6 got hangup request
    -- Hungup 'Zap/1-1'
    -- Hungup 'Zap/16-1'
    -- Accepting voice call from '7674603xxxx' to '26' on channel 0/1, span 1
    -- Executing Dial("Zap/1-1", "Zap/g2/26")
    -- Requested transfer capability: 0x00 - SPEECH
    -- Called g2/26
    -- Zap/7-1 is proceeding passing it to Zap/1-1
    -- Zap/7-1 is ringing
    -- Zap/7-1 answered Zap/1-1
    -- Attempting native bridge of Zap/1-1 and Zap/7-1
Jan 25 08:06:35 WARNING[3318]: chan_zap.c:8162 zt_pri_error: 2 TEI remove TEI = 0
Jan 25 08:06:36 WARNING[3318]: chan_zap.c:8162 zt_pri_error: 2 TEI remove TEI = 0
    -- Remote UNIX connection
Jan 25 08:08:48 WARNING[3317]: chan_zap.c:8162 zt_pri_error: 1 TEI remove TEI = 0
Jan 25 08:08:49 WARNING[3317]: chan_zap.c:8162 zt_pri_error: 1 TEI remove TEI = 0
    -- Executing Macro("SIP/ZelC-74f1", "SIPfirmaintern|BS01|9502")
    -- Executing SetLanguage("SIP/ZelC-74f1", "de") in new stack
    -- Executing SetCIDNum("SIP/ZelC-74f1", "9044") in new stack
    -- Executing NoOp("SIP/ZelC-74f1", "9502") in new stack
    -- Executing Dial("SIP/ZelC-74f1", "SIP/BS01|60|tr") in new stack
    -- Called BS01
    -- SIP/BS01-9099 is ringing
    -- SIP/BS01-9099 answered SIP/ZelC-74f1
    -- Attempting native bridge of SIP/ZelC-74f1 and SIP/BS01-9099
    -- Executing GotoIf("SIP/ZelC-74f1", "0?112") in new stack

Wie du siehst kommt die Seeding-Message nicht bei jedem Anwählen eines Teilnehmers. Die fett markierten CLI-Ausgaben zeigen sogar dass die Seeding-Message auch nicht immer bei einer Registrierung kommen. Bei mir tauchen diese Seeding-Messages sowieso total sporadisch auf.
lg Dani