Unbeantworteter Anruf bei Blindtransfer (speziell mit SNOM Telefonen)

[IEEE]

Ich suche gerade Inspiration zu folgendem Thema:

Wie ich feststellen musste, schule ich meinen Anwendern den Blindtransfer auf etwas ungünstige Weise. Ich empfehle immer, zuerst mal den aktuellen Anrufer mit HOLD zu halten. Dann den Zielteilnehmer anrufen und DANN während des Klingelns auf Transfer zu drücken. Oder eben doch warten bis das Ziel abhebt und dann doch einen Transfer mit Rückfrage zu machen.
Der Vorteil daran ist, dass ich nur EINE Transfer Methode schulen muss (der Anwender entscheidet selbst, ob er einen Transfer mit oder ohne Rückfrage macht, einfach schlicht dadurch ob er während des Klingelns schon auf Transfer drückt) was Anwendern die sich ohnehin schwer tun, ein neues Telefon zu erlernen, entgegenkommt.

Der Nachteil an dieser Variante ist, dass in dem Moment wo TRANSFER gedrückt wird, der aktuelle Anruf (CANCEL) abgebrochen wird und für den durchgestellten Call ein völlig neuer Channel aufgebaut wird. Dies hinterlässt dann einen unbeantworteten Anruf auf dem Zieltelefon. Das ist etwas störend.

Mir ist klar, dass eigentlich für einen Blindtransfer ein anderer Weg empfohlen wird (gleich auf Transfer drücken, Zielnummer eingeben). Ich habe aber meine Methode irgendwie liebgewonnen und sie hat eben wie gesagt den Vorteil, dass man sich noch während des Klingelns auf einen Transfer MIT Rückfrage "um-entscheiden" kann.

Gut, ich jetzt hab ich also überlegt wie ich diesen unbeantworteten Anruf bei diesem Szenario weg kriege. Neuere Firmwareversionen der SNOMs haben hier ja eine ganz nette Einstellung: http://wiki.snom.com/Settings/sip_cancel_reasons_to_ignore_missed_call
Hier kann man Reasons oder Causes der CANCEL Nachricht angeben, bei denen dann KEIN unbeantworteter Anruf erstellt wird. Die Frage ist aber, wie krieg ich Asterisk dazu, hier einen bestimmten Cause zu senden? Ich hab den Vorgang mal beobachtet, das SNOM sendet im Cancel einfach nur ein "Normal Call Clearing"... Asterisk selbst sendet einfach ein CANCEL ohne Reason.

Hat zufällig auch schonmal jemand über dieses Thema nachgedacht und einen Tipp?

 

[rentier-s]

Mir fällt dazu nur ein, den Anruf irgendwie als Vermittlungsversuch zu erkennen, zB. anhand der offenen Kanäle dieser Nst, und abhängig davon im Dial das Flag c zu setzen. :noidea:

 

[abw1oim]

@rentier-s: Ich fürchte, das wird nichts: Man kann zwar ein solches Verfahren bauen, aber c bewirkt ja nichts, weil der Call eben nicht "elsewhere" beantwortet wird. Man könnte höchstens tricksen und einen weiteren Channel (Local) aufbauen, der ein Wait hat, dass etwa dem Ringtimeout an dem eigentlichen Ziel entspricht und danach ein Answer() im Local-Teil werfen, dann würde c etwas bringen ... Dabei kommen natürlich auch noch die CDRs durcheinander, schön wird das also bestimmt nicht.

Mein Grübeln zum Thema hat leider auch kein durchschlagendes Ergebnis erbracht ...

 

[rentier-s]

Das c sorgt dafür, dass Asterisk den Anruf bzw. das Cancel als Call-Completed-Elsewhere deklariert, obwohl das nicht unbedingt so sein muss. Ich benutze das, um zB. Anrufe von der Türsprechanlage nicht in der Anrufliste zu haben.

Dial(SIP/121)

CANCEL sip:[email protected]:45085;transport=TCP;ob SIP/2.0
Via: SIP/2.0/TCP 192.168.0.100:5060;branch=z9hG4bK4a8ee4ab
Max-Forwards: 70
From: "Console" <sip:[email protected]>;tag=as543213d1
To: <sip:[email protected]:45085;transport=TCP;ob>
Call-ID: [email protected]:5060
CSeq: 102 CANCEL
User-Agent: Asterisk11
Content-Length: 0

Dial(SIP/121,,c)

CANCEL sip:[email protected]:45085;transport=TCP;ob SIP/2.0
Via: SIP/2.0/TCP 192.168.0.100:5060;branch=z9hG4bK3171ef7d
Max-Forwards: 70
From: "Console" <sip:[email protected]>;tag=as70c90efe
To: <sip:[email protected]:45085;transport=TCP;ob>
Call-ID: [email protected]:5060
CSeq: 102 CANCEL
User-Agent: Asterisk11
[COLOR="#FF0000"]Reason: SIP;cause=200;text="Call completed elsewhere"
[/COLOR]Content-Length: 0

 

[IEEE]

Das c Flag wäre grundsätzlich schon in Ordnung. Es würde das tun was ich brauche, allerdings: Wann immer ich über die sinnvolle Verwendung des c Flags nachdenke, komme ich zu dem Schluss dass ich dafür in die Zukunft schauen können müsste. So wie hier, ich müsste vorher WISSEN, dass es ein Vermittlungsanruf ist. Der Ansatz, dass man versucht das anhand der offenen Kanäle zu erkennen ist schon mal gar nicht so schlecht, danke. Wenngleich - nur weil jemand gerade einen gehaltenen Anruf hat, muss das noch lange nicht heissen, dass er vor hat zu verbinden.

Mir ist auch aufgefallen, dass es zu dem unbeantworteten Anruf nicht nur bei der von mir geschulten Methode kommt. Wir aktivieren ja auch immer das Transfer bei auflegen. Viele sind das von der alten Anlage noch gewohnt so durchzustellen (Nebenstelle wählen - zack auflegen). Auch hier entsteht natürlich ein unbeantworter Anruf...

 

[abw1oim]

Das ist ja interessant: Ich wußte noch gar nicht, dass ein "einfaches" Cancel (und nicht nur ein Cancel im Zuge eines Answers an anderer Stelle) tatsächlich ein CallCompletedElswhere zu schicken vermag ...

Aber: Du hast recht, habe es gerade nachstellen können.

Damit wäre es in der Tat so, dass man in der Ausgangssituation beim OP vor dem Dial nir feststellen müsste, dass es einen Channel gibt, bei dem das anfordernde Telefon B-Party war (und der aktuell on Hold ist), um dann im Dial ein c zu spendieren ...

Ich werde mir mal interessehalber das Vorgehen des OP und die zugehörigen SIP-Pakete in einer Testumgebung anschauen.

@IEEE: Das Problem mit Transfer bei Auflegen ist aber in der Tat identisch. Wo ich bei Dir bin ist die Tatsache, dass man natürlich nicht weiß, ob es ein Transfer- oder ein "echter" Anruf ist, es sei denn Snom meldet zumindest mal beim direkten Drücken der Transfer-Taste (Transfer mit Auflegen) irgendetwas Besonderes in den SIP-Headern, das man auswerten kann. Für die Methode Hold/Transfer kann man aber in der Tat nicht zwischen Hold und "echtem" Rückfrage-/Parallelcall und Hold zum Zwecke des Transfers unterscheiden. Da müsste man dann IMHO "einen Tod sterben" ...

 

[IEEE]

Um ehrlich zu sein wundert es mich, dass das nicht viele andere Leute stört ;-) Als ich begonnen habe mich mit dem Problem zu beschäftigen, hätte ich eigentlich mit dutzenden Postings von Leuten gerechnet, die sich damit herumschlagen.

Nachtrag:
Wenn zumindest das SNOM bei so einem "Auflegen via Transfer" irgendeinen speziellen Cause schicken könnte, dann könnte man damit vielleicht arbeiten...

Nachtrag 2:
Schade ist übrigens auch, dass bei weitem nicht alle gängigen Telefone auf dieses "Call completed elsewhere" reagieren. Mir selbst sind eigentlich nur die SNOM bekannt, die das auswerten.

 

[rentier-s]

Um ehrlich zu sein wundert es mich, dass das nicht viele andere Leute stört

Also ich kann ja nur mit Erfahrungen von einer einzigen Anlage dienen, aber da konnte ich das nicht beobachten. Dort sind Snom 370 und ein m9 im Einsatz und es wird häufig vom Haupttelefon (einziges von extern direkt erreichbares) an die anderen vermittelt, mit und ohne Rückfrage. Allerdings ausschließlich per BLF Tasten, vielleicht macht das den Unterschied. Ich müsste da direkt mal hinfahren und mir ein SIP Debug ansehen, wie das protokoll-mäßig genau abläuft.

Wenn zumindest das SNOM bei so einem "[Transfer durch Auflegen]" irgendeinen speziellen Cause schicken könnte

Wende Dich doch mal an den Snom Support, die sind da eigentlich recht offen für solche Anregungen.