[gelöst] snom 320 + BLF + 3 Asterisk

[shrimps24]

Hallo ip-phone-forum.

ich habe hier ein snom 320 mit drei Identitäten und drei verschiedenen Asterisks-Server. Das Umschalten zwischen den Identitäten funktioniert reibungslos, die Anrufe werden auch jeweils auf dem entsprechenden Server durchgeführt.

Allerdings scheinen die Subscription manchmal an einen anderen Server durchzugehen. Folgende Tasten habe ich wie folgt als BLF hinterlegt:

fkey0!: blf <sip:[email protected];user=phone>|*8
fkey1!: blf <sip:[email protected];user=phone>|*8
fkey2!: blf <sip:[B][email protected][/B];user=phone>|*8
fkey3!: blf <sip:[email protected];user=phone>|*8
fkey4!: blf <sip:[email protected]:5061;user=phone>
fkey5!: blf <sip:[email protected]:5061;user=phone>
fkey6!: keyevent F_REDIRECT:017281XXXXX
fkey7!: keyevent F_REDIRECT:10
fkey8!: keyevent F_REDIRECT:11
fkey9!: blf <sip:[email protected]:5061;user=phone>
fkey10!: blf <sip:[email protected];user=phone>

Im Prinzip müsste die Nebenstelle 12 über den Ast 192.168.10.253 laufen. Stattdessen sehe ich folgendes auf dem Ast 192.168.5.8:

tk-server*CLI> sip show subscriptions
Peer             User        Call ID      Extension        Last state     Type            Mailbox
192.168.10.126   98          3c26701b214  --               <none>         mwi             10
192.168.10.126   98          3c26701a81b  [B]12@intern[/B]        Idle           dialog-info+xml <none>
192.168.10.126   98          3c26701a833  05@intern        Idle           dialog-info+xml <none>
192.168.10.126   98          3c26701a83f  13@intern        Idle           dialog-info+xml <none>

Die Asterisk-Server sind über mehrere VPN-Tunnel gekoppelt, die Kommunikation an sich funktioniert reibungslos. Lediglich das Problem, dass manchmal die Subscriptions auf dem falschen Server ankommen.

Irgendjemand der Profis eine Idee?

MfG
shrimps

 

[Tiny_Dragon]

Ich gehe mal davon aus, dass das Telefon, die IP-Adresse und die Subscription zueinander passen.

Mal abgesehen davon dass es den Anschein hat nicht so sein zu sollen, wie verhält sich das Telefon dabei? Verarbeitet es diese Subscription und kommt es dadurch zu fehlern?

Was sind die verwendeten Versionen der *-Anlagen und des Telefons? Diese Informationen sind hilfreich um dieses Verhalten mal nachstellen zu können.

 

[shrimps24]

Hallo Tiny_Dragon,

vielen Dank für die schnelle Antwort. Also IP-Adressen und Subscriptions passen; Wenn ich testweise nur eine Identität nutze, dann funktioniert auch die Subscription korrekt. Das Problem tritt scheinbar wirklich nur auf, wenn die Identitäten auf mehreren Asterisks verteilt sind.

Identität 1 - SIP/12: Der 192.168.10.253er ist Version SVN-branch-1.4-r181990.
Identität 2 - SIP/98: Der 192.168.5.8er ist Version 1.4.21.
Identität 3 - SIP/98: Der 192.168.12.9er ist Version 1.4.21.1.
Das entsprechende Snom ist Version snom320-SIP 7.3.14.

An den anderen Asterisk-Servern hängen im jeweils lokalen Netzwerk auch Snom-Telefone, bei denen mit jeweils einer Identität die BLFs reibungslos funktionieren.

Wenn ich bsp.weise fkey2 drücke mit der Identität 1, dann wird der Anruf (SIP/12) über den Server der hinterlegten Identität richtig durchgeführt, allerdings funktionieren dann nicht die BLFs, weil die Subscriptions laut Asterisk über den 192.168.5.8 laufen.

Wenn ich das Snom neustarte, dann finden die Subscriptions überwiegend richtig statt. Aber mindestens eine BLF ist immer dabei, die dann auf dem falschen Server die Subscription vornimmt.

Hier noch eine aktive Übersicht der Subscriptions aus snom-Sicht. Die falschen IP-Adressen habe ich markiert:

From  	To 	Event  	Expires
[email protected]	[email protected]	message-summary	Retry in 114 sec
[email protected]	[email protected]	dialog	414
[email protected]	[email protected]	message-summary	414
[email protected]	[email protected]	message-summary	413
98@[B]192.168.5.8[/B]	[email protected]	dialog	Retry in 414 sec
98@[B]192.168.5.8[/B]	[email protected]	dialog	Retry in 414 sec
98@[B]192.168.5.8[/B]	[email protected]	dialog	Retry in 414 sec
[email protected]	[email protected]	dialog	413
[email protected]	[email protected]	dialog	413
98@[B]192.168.5.8[/B]	[email protected]	dialog	Retry in 414 sec
98@[B]192.168.5.8[/B]	[email protected]	dialog	413
98@[B]192.168.5.8[/B]	[email protected]	dialog	Retry in 1014 sec

Vielen Dank im Voraus.

 

[shrimps24]

Irgendwie scheint es, als ob das snom seine Subscriptions auf die Server nach Belieben verteilt. Nach einem Neustart des Snom's sehen die Subscriptions wie folgt aus:

From  	To 	Event  	Expires
[email protected]	[email protected]	dialog	1741
[email protected]	[email protected]	message-summary	1741
[email protected]	[email protected]	message-summary	1740
[email protected]	[email protected]	dialog	1740
[email protected]	[email protected]	dialog	1740
[B][email protected][/B]	[email protected]	dialog	1740
[B][email protected][/B]	[email protected]	dialog	Retry in 540 sec
[B][email protected][/B]	[email protected]	dialog	Retry in 540 sec
[email protected]	[email protected]	dialog	1740
[email protected]	[email protected]	dialog	1741
[email protected]	[email protected]	dialog	1741

 

[Ottone]

Hast Du im SNOM einen "outbound proxy" eingetragen? Wenn ja dann einmal entfernen und sehen was passiert. Ich vermute allerdings stark dass Du keinen proxy dort hast - für mich sieht das sehr nach einem bug in firmware 7.3.14 aus.

Frage: Hängt das Ergbnis evtl. davon ab welche Identität die aktive ist direkt nachdem Du das Telefon neu gestartest hast?

 

[shrimps24]

Ein Outbound-Proxy stand in jeder Identität. Ich habe nun testweise den Outbound-proxy rausgeschmissen und das Snom neugestartet, allerdings keine Änderung.

Auf dem 192.186.5.8 taucht nun auch folg. Meldung auf:

chan_sip.c:14997 handle_request_subscribe: Failed to authenticate user <sip:[email protected]>;tag=1t88jsiypb for SUBSCRIBE

Die Subscriptions schauen ohne Outbound-Proxy nun wie folgt aus:

From  	To 	Event  	Expires
[email protected]	[email protected]	dialog	1762
[email protected]	[email protected]	message-summary	1762
[email protected]	[email protected]	message-summary	1761
[email protected]	[email protected]	dialog	1761
[email protected]	[email protected]	dialog	1761
[B][email protected][/B]	[email protected]	dialog	Retry in 561 sec
[B][email protected][/B]	[email protected]	dialog	Retry in 561 sec
[B][email protected][/B]	[email protected]	dialog	Retry in 561 sec
[email protected]	[email protected]	dialog	1761
[email protected]	[email protected]	dialog	1761
[email protected]	[email protected]	dialog	1761

Vielen Dank im Voraus.

 

[shrimps24]

Hab mich schon gefreut, dass der snom-Support mitwerkelt. Hat Tiny_Dragon keinen neuen Tipp für mich?

 

[Tiny_Dragon]

Bitte lege mal bei den BLFs die Identität fest. Einfach von Aktive auf die jeweilige Identität festlegen.

BR

 

[shrimps24]

Hm, das ist auch ne Idee... Bei den BLFs stand überall "aktive". Das Ändern auf die jeweiligen Identitäten bringt leider keinen Erfolg. Habe nach dem Setzen der Identitäten das Snom neugestartet. Die Subscriptions finden leider immer noch auf den falschen Servern statt:

From  	To 	Event  	Expires
[email protected]	[email protected]	dialog	Trying
[email protected]	[email protected]	dialog	Trying
[email protected]	[email protected]	dialog	Trying
[B][email protected][/B]	[email protected]	dialog	Trying
[B][email protected][/B]	[email protected]	dialog	Trying
[B][email protected][/B]	[email protected]	dialog	Trying
[email protected]	[email protected]	dialog	Trying
[email protected]	[email protected]	dialog	Trying
[email protected]	[email protected]	message-summary	Retry in 514 sec
[email protected]	[email protected]	message-summary	Retry in 510 sec
[B][email protected][/B]	[email protected]	dialog	Retry in 505 sec
[B][email protected][/B]	[email protected]	dialog	Retry in 505 sec
[B][email protected][/B]	[email protected]	dialog	Retry in 505 sec

Vielen Dank im Voraus für Deine Bemühungen...

 

[shrimps24]

Danke an Tiny_Dragon. Der Tipp mit dem Setzen der jeweiligen Identität hat das Problem zu 99% gelöst

Es sind zwar immer noch vereinzelt Subscriptions, die auf dem falschen Server landen, aber damit kann ich leben, so lange die "meisten" richtig funktionieren.

Darauf hätte man auch selbst kommen können. Ich bin nur eben davon ausgegangen, dass das Snom anhand der IP-Adresse, die im BLF hinterlegt ist, weiss, wohin er seine Subscriptions schicken soll.

Vielen Dank für die Bemühungen...