Weiterleitung bei Nichtmelden nach Transfer

[anonymous]

Hallo,

folgende Umgebung:

3CX V11 SP4 (3CXPSSB Lizenz)

snom 370 als Tischtelefone
diverse DECT analogtelefone an Grandstream GXW-4008
als Trunk kommt eine BeroNet mit 4 BRI Ports zum Einsatz

Nun ist mein Problem, dass ein eingehender Anruf (meist von extern) auf einem snom weiterverbunden wird (zu einem anderen snom, oder auch einem analogen Gerät). Das Weiterverbinden geschieht mittels snom Option "transfer_on_hangup = 0n", also mit zwei verbundenen Gesprächen und einfach auflegen.

Nun kommt es vor, dass die Person, zu der man verbindet nicht abnimmt.

Gibt es hier irgendeine Möglichkeit das Gespräch:
A.: Wieder zurück auf das Gerät zu leiten, was weiterverbunden hat
B.: Auf irgendetwas zu leiten nach Timeout (Signalisierungsgruppe, etc)

A funktioniert vermutlich nicht, siehe auch hier:
http: //3cx.ideascale.com/a/dtd/If-no-answer-or-busy-on-blind-transfer-return-to-transferor/305838-9854

Bei B dachte ich, dass es über die Weiterleitungsregeln gehen müsste ("Nicht angenommen" innerhalb z.B. 30 Sekunden --> auf Signalisierungsgruppe leiten).
Die Weiterleitungsregeln scheinen aber grundsätzlich nur bei "neuen" Gesprächen zu greifen und nicht bei Gesprächen, die mittels Transfer weiterverbunden werden.

Gibt es irgendeine Lösung für mein Problem?

Viele Grüße
Sebastian

 

[rgrunert]

B: vielleicht ähnlich wie hier: https://www.3cx.de/topic/nur-von-intern-zu-erreichen/

Zeit=30 und "interne Anrufe abweichend behandeln" auf Sammelanschluss schicken, ist nur ne Idee und nicht getestet

 

[anonymous]

@rgrunert wrote:B: vielleicht ähnlich wie hier: https://www.3cx.de/topic/nur-von-intern-zu-erreichen/

Zeit=30 und "interne Anrufe abweichend behandeln" auf Sammelanschluss schicken, ist nur ne Idee und nicht getestet

Ich habe die Nebenstelle schon grundsätzlich auf 30 Sekunden und Weiterleitung auf Signalisierungsgruppe eingestellt. Das interne abweichend behandeln wäre ja nur eine weitere Einschränkung.
Das funktioniert auch, wenn es ein "neuer" Anruf ist (egal ob intern oder extern) aber sobald der Anruf per Transfer auf diese Nebenstelle verbunden wird, scheint er die Einstellung zu ignorieren.

 

[matictec]

Die Weiterleitung sollte an sich dennoch funktionieren. Hier müsste man sich die Logs mal im Detail anschauen um genauer sagen zu können, was passiert.

 

[anonymous]

Hi,

hat etwas gedauert, bis ich mal wieder vor Ort war. Anbei das Logfile.

In diesem Test habe ich:
- Mit der (Nummer ausgetauscht) Rufnummer: 01791234567 angerufen
- An der Nebenstelle 25 abgenommen
- An die Nebenstelle 12 verbunden
- gut eine Minute gewartet
- dann aufgelegt

Gemäß Weiterleitungsregeln hätte nach 30 Sekunden eine Weiterleitung an eine Signalisierungsgruppe erfolgen sollen.

Kann jemand den Grund erkennen, warum das nicht so geklappt hat?

Danke

Viele Grüße
Sebastian

 

[matictec]

Warum das letztendlich scheitert, kann ich zwar nicht genau sagen, aber es kommt auf jeden Fall zu einem Fehler mit der 12:

02-Jan-2014 14:21:32.850 Provisional(180) from ;tag=o1hh7e90n3 to "Sebastian Chrostek";tag=b809c725
02-Jan-2014 14:21:32.849 [CM505001]: Endpoint Extn:12: Device info: Device Identified: [Man: Snom;Mod: 3xx series;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [snom370/8.7.3.25] PBX contact: [sip:[email protected]:5060]
02-Jan-2014 14:21:32.849 [CM503002]: Call(C:901): Alerting Extn:12 by contact
02-Jan-2014 14:21:32.845 UacSession 609656 has formed leg L:901.8[Extn:12]
02-Jan-2014 14:21:32.845 Answer from ;tag=o1hh7e90n3 to "Sebastian Chrostek";tag=b809c725
02-Jan-2014 14:21:31.735 L:902.1[Extn:25]: Terminating targets, reason:
02-Jan-2014 14:21:31.734 Leg L:902.1[Extn:25] is terminated: Cause: BYE from PBX
02-Jan-2014 14:21:31.734 Terminated from " Lager 2";tag=dafcfqr4k8 to ;tag=ac12db00; reason: Rejected
02-Jan-2014 14:21:31.734 L:902.1[Extn:25] Sending: OnSendResp Send 406/INVITE from 0.0.0.0:0 tid=-9rfdbnmoxd34 Call-ID=52c56863194b-5qdk821lcz7j:
SIP/2.0 406 Not Acceptable
Via: SIP/2.0/UDP 192.168.2.134:1024;branch=z9hG4bK-9rfdbnmoxd34;rport=1024
To: ;tag=ac12db00
From: " Lager 2";tag=dafcfqr4k8
Call-ID: 52c56863194b-5qdk821lcz7j
CSeq: 2 INVITE
Warning: 499 3CX.ahw.local "Terminated"
Content-Length: 0
02-Jan-2014 14:21:31.734 SendMsg from ;tag=ac12db00 to " Lager 2";tag=dafcfqr4k8
02-Jan-2014 14:21:31.707 Call(C:902) is terminated
02-Jan-2014 14:21:31.704 [CM503020]: Call(C:902): Normal call termination. Call originator: Extn:25. Reason: Terminated
02-Jan-2014 14:21:31.703 [CM503016]: Call(C:902): Attempt to reach from Extn:25 has failed. Reason: User Requested

Handelt es sich um eine blinde Weiterleitung (TRANSF > 12 > OK) oder um die Hang Up Variante (Zweiter Call an 12 > Hangup)? Bitte mal erstere Variante prüfen.

 

[anonymous]

Es handelt sich um die zweite Variante (Zweiter Call an 12 > Hangup).

Interessanterweise funktioniert es wirklich, wenn ich die erste Variante nehme ... (TRANSF > 12 > OK)

Allerdings sind das zwei Tastendrücke mehr und es ist doch eigentlich beides eine blinde Weiterleitung ohne Rücksprache. Sollte sich das System da nicht identisch verhalten?

 

[matictec]

Ist das Telefon provisioniert?

 

[anonymous]

Ja, aber nicht mit der Standard Datei. Ich habe meine mal angehängt.

 

[anonymous]

Hat keiner eine Idee, wo das Problem liegt?

 

[matictec]

Prüf doch einfach mal mit den Standard-Templates. Wie ist zudem das Beronet Gateway konfiguriert, manuell oder über 3CX? Alternativ auch noch mal die 302 Weiterleitung im snom deaktivieren.

 

[anonymous]

Im Standard Template ist dieser Wert nicht vorhanden:

http://wiki.snom.com/Settings/transfer_on_hangup

Und hier ist laut dem Wiki der Standard Wert = off

D.h. mit dem Standard-Template von 3CX funktioniert ein Transfer beim Auflegen garnicht. Da geht nur die andere Methode mit dem Transfer Button - und die funktioniert ja sowieso.

Das Beronet Gateway ist manuell konfiguriert. Die Konfiguration über 3CX gibt es doch erst in v12, oder?

Mit "302 Weiterleitung deaktivieren" meinst du diese Option?:
http://wiki.snom.com/Settings/disable_deflection

 

[anonymous]

Könnte das was damit zu tun haben?

http://wiki.snom.com/Firmware/V8/Release_Notes/Change_Log_V8_7_4

SCPP-2704: phone should not ignore HTTP 302 response instead make a new request to the provided location

Die Firmware ist aber noch Beta ...