Call Deflection wenn 2 Leitungen belegt: zapcd

[speedy1980]

Hallo,
Hat jemand schon einmal zapcd benutzt, um bei zwei belegten B-Kanälen einer ISDN Leitung den Anrufer auf eine zweite ISDN Leitung umzuleiten?
Problemstellung: Asterisk mit 2 ISDN Anschlüssen, es sind also insgesamt 4 Gespräche möglich. Angerufen wird immer auf den ersten Anschluss, weil das die Hauptnummer ist. Wenn nun beim ersten ISDN Anschluss die beiden Leitungen belegt sind, dann bekommt der Anrufer ein Besetzt-Zeichen. Gut wäre es aber, wenn man hier mittels zapcd den Anrufer auf die zweite ISDN Leitung legen könnte. Asterisk bekommt ja mit, dass ein dritter Anrufer da ist:

4 < Protocol Discriminator: Q.931 (8)  len=45
4 < Call Ref: len= 1 (reference 23/0x17) (Originator)
4 < Message type: SETUP (5)
4 < [a1]
4 < Sending Complete (len= 1)
4 < [04 03 80 90 a3]
4 < Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
4 <                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
4 <                              Ext: 1  User information layer 1: A-Law (35)
4 < [18 01 80]
4 < Channel ID (len= 3) [ Ext: 1  IntID: Implicit, Other Spare: 0, Preferred Dchan: 0
4 <                        ChanSel: No channel selected
4                          ]
4 < [6c 10 01 83 30 30 34 39 31 37 30 XX XX XX XX XX XX]
4 < Calling Number (len=18) [ Ext: 0  TON: Unknown Number Type (0)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
4 <                           Presentation: Presentation allowed of network provided number (3) '0049170XXXXXX' ]
4 < [70 08 c1 32 34 XX XX XX XX XX]
4 < Called Number (len=10) [ Ext: 1  TON: Subscriber Number (4)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '242XXXX' ]
4 < [7d 02 91 81]
4 < High-layer compatibilty (len= 4) [ 4 0x91 4 0x81 4  ]
4 -- Making new call for cr 23
4 -- Processing Q.931 Call Setup
4 -- Processing IE 161 (cs0, Sending Complete)
4 -- Processing IE 4 (cs0, Bearer Capability)
4 -- Processing IE 24 (cs0, Channel Identification)
4 -- Processing IE 108 (cs0, Calling Party Number)
4 -- Processing IE 112 (cs0, Called Party Number)
4 -- Processing IE 125 (cs0, High-layer Compatibility)
4 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Call Present, peerstate Call Initiated
4 > Protocol Discriminator: Q.931 (8)  len=8
4 > Call Ref: len= 1 (reference 151/0x97) (Terminator)
4 > Message type: RELEASE COMPLETE (90)
4 > [08 02 80 ac]
4 > Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: User (0)
4 >                  Ext: 1  Cause: Requested channel not available (44), class = Network Congestion (2) ]
4 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
4 NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null

Aber im Wählplan passiert beim dritten Anruf ja nichts, ich kann also gar kein zapcd ausführen. Hat jemand eine Idee?

 

[wpfundstein]

Hi,

Wenn das 2 getrennte ISDN Anschlüsse (Mehrgeräteanschluss) sind, wie soll das dann gehen?

Geht nur bei einem Anlagenanschluss mit mehreren NTBAs

Gruß, Werner

 

[speedy1980]

Naja signalisiert wird der dritte Anruf ja auf dem D-Kanal. Also sollte man ihn auch umleiten können.

 

[wpfundstein]

Also hast Du 2 Mehrgeräteanschlüsse, richtig?

Du kannst nicht einen Anruf, der am ersten Anschluss rein kommt, über den zweiten Anschluss umleiten. Dazu brauchst Du einen Anlagenanschluss.

 

[speedy1980]

Richtig, zwei Mehrgeräteanschlüsse. Wie würde es denn beim Anlagenanschluss aussehen, wie leite ich da um?

 

[wpfundstein]

Bei einem Anlagenanschluss gehören die NTBAs ja zusammen. Ist im Gesamten ein Anschluss. Somit funktioniert ZapCD wieder.

 

[speedy1980]

Gut, aber wie mache ich es bei einem Anlagenanschluss? Hast Du einen Wählplanschnipsel für mich?

 

[wpfundstein]

na mit

ZapCD(Rufnummer)

oder verstehe ich dich falsch?

 

[speedy1980]

Naja der Wählplan sprint gar nicht an, weil die B-Kanäle ja belegt sind .... Aber gut, ich werde mir mal einen Anlagenanschluss mit Asterisk selbst machen (NT) und mir das dann ansehen...
Mich wundert die Sache trotzdem. Asterisk bekommt ja mit, dass auf dem D-Kanal was los ist. Und irgendwie sollte man da doch was machen können.

 

[clan]

Also hast Du 2 Mehrgeräteanschlüsse, richtig?

Du kannst nicht einen Anruf, der am ersten Anschluss rein kommt, über den zweiten Anschluss umleiten. Dazu brauchst Du einen Anlagenanschluss.

Ich glaube, du bringst da was durcheinander. Der Anlagenanschluß ist logisch ein Anschluß, bei dem alle S0-Leitungen den gleichen Nummernblock haben. Solange irgendeiner der B-Kanäle frei ist, wird der Ruf auf einer Leitung mit freien B-Kanal signalisiert.

CD (Call Deflection) ist zur Rufumleitung während es klingelt und sollte bei zwei Mehrgeräteanschlüssen tatsächlich funktionieren, wenn denn der dritte Anruf in irgendeinem Kontext im Asterisk ankommen würde. Um den Anruf beim Anlagenanschluß auf die andere Leitung umzuleiten ist CD hier eher untauglich.

 

[wpfundstein]

Hi Clan,

das glaube ich weniger. Wie soll das funktionieren?

Beispiel:

Wir haben zwei Mehrgeräteanschlüsse A und B

Jetzt kommt ein Gespräch auf A rein und wird angenommen. ok. Jetzt kommt noch mal ein Gespräch rein. Dieses kann mit ZapCD im Amt umgeleitet werden.Auch ok. Angenommen es werden 2 Gespräche geführt, also beide B-Kanäle belegt. In diesem Fall passiert nichts mehr. Hab ich so an meinem Anschluss festgestellt. Hast Du allerdings einen Anlagenanschluss mit 2 NTBAs, dann kann das 3.eingehende Gespräch mit ZapCD jedoch behandelt werden, da ja noch 2 B-Kanäle frei sind.

Bei 2 Mehrgeräte Anschlüsse geht das eben nicht. Die gehören weder logisch noch physikalisch zusammen.

Gruß, Werner

 

[speedy1980]

...
Hast Du allerdings einen Anlagenanschluss mit 2 NTBAs, dann kann das 3.eingehende Gespräch mit ZapCD jedoch behandelt werden, da ja noch 2 B-Kanäle frei sind.

Bei 2 Mehrgeräte Anschlüsse geht das eben nicht. Die gehören weder logisch noch physikalisch zusammen.

Gruß, Werner

Also würde bei Dir das 3. Gespräch auf dem 2. NTBA reinkommen (womit auf diesem kein B-Kanal belegt ist) und Du würdest es dort umleiten? Das ist mir klar, dass das geht. Wir haben wohl aneinander vorbei geredet
Ich war der Meinung man könne mit zapcd einen dritten Anrufer auf einem NTBA (2 sprechen, ein dritter kommt noch dazu) über den D-Kanal umleiten (bei mir dann auf den 2. ISDN Anschluss).
Wie bereits geschrieben: Es sind 2 Mehrgeräteanschlüsse vorhanden. Die Kunden rufen immer auf der Hauptnummer des ersten Anschlusses an. Wenn nun der erste Mehrgeräteanschluss mit 2 Gesprächen belegt ist sollen die Gespräche auf dem zweiten Mehrgeräteanschluss landen. Natürlich soll dann der Kunde nicht auflegen und die Nummer des zweiten Anschlusses wählen müssen.

Danke @clan, Du scheinst mich verstanden zu haben.

 

[cibi]

Ich habe das nur kurz probiert, ohne CD (muss gleich weg...) :
Bei Capi (Fritzcard) wird ein Anruf signalisiert wenn beide Kanäle belegt sind.
Es wird ein Pseudo Kanal erstellt

CAPI/CISDN1-pseudo-D 908070@isdnextern_in Ring    Dial(SIP/16|60|tw)

Diesen sollte man dann auch umleiten können.
(Sip Telefon, hier 16 klingelt auch).

Ich hoffe ich habe das jetzt nicht falsch verstanden, aber das ist doch das normale ISDN Verhalten (außer es ist besetzt bei besetzt aktiviert), oder?

Das müsste dann eigentlich auch mit Zap/bristuff gehen.

 

[clan]

Ich habe das nur kurz probiert, ohne CD (muss gleich weg...) :
Bei Capi (Fritzcard) wird ein Anruf signalisiert wenn beide Kanäle belegt sind.
Es wird ein Pseudo Kanal erstellt

CAPI/CISDN1-pseudo-D 908070@isdnextern_in Ring    Dial(SIP/16|60|tw)

Diesen sollte man dann auch umleiten können.
(Sip Telefon, hier 16 klingelt auch).

Ich hoffe ich habe das jetzt nicht falsch verstanden, aber das ist doch das normale ISDN Verhalten (außer es ist besetzt bei besetzt aktiviert), oder?

Das müsste dann eigentlich auch mit Zap/bristuff gehen.

Wie ich oben schrieb:

... wenn denn der dritte Anruf in irgendeinem Kontext im Asterisk ankommen würde

Die Zap-Treiber unterstützen das, soweit ich weiß, bisher leider nicht.

 

[clan]

das glaube ich weniger. Wie soll das funktionieren?

Beispiel:

Wir haben zwei Mehrgeräteanschlüsse A und B

Jetzt kommt ein Gespräch auf A rein und wird angenommen. ok. Jetzt kommt noch mal ein Gespräch rein. Dieses kann mit ZapCD im Amt umgeleitet werden.Auch ok. Angenommen es werden 2 Gespräche geführt, also beide B-Kanäle belegt. In diesem Fall passiert nichts mehr. Hab ich so an meinem Anschluss festgestellt.

Wenn du mal auf den D-Kanal schaust wirst du feststellen, daß der dritte Anruf trotzdem signalisiert wird, das nennt man dann anklopfen. Den Ruf kann man per CD umleiten, oder auch (im Amt) makeln. Leider können die Zaptel-Treiber damit nicht umgehen und ignorieren das Gespräch, anstatt, wie anscheinend die Capi-Treiber, einen Pseudo-Channel bereit zu stellen.

 

[speedy1980]

Ich danke Euch. Damit wäre die Sache also geklärt - mit Bristuff und Zap komme ich in dieser Sache so nicht weiter.

 

[torstenkrueger]

Bei einem Anlagenanschluss gehören die NTBAs ja zusammen. Ist im Gesamten ein Anschluss. Somit funktioniert ZapCD wieder.

ZapCD funktioniert am Anlagenanschluß leider nicht, da hierfür eine andere Facility benötigt würde, nämlich reroute. Und die ist in Bristuff nicht implementiert.

 

[wpfundstein]

@torstenkrueger

dann frage ich mich warum es bei mir mit ZapCD am Anlagenanschluss funktioniert.

 

[amcu]

genau mit bristuffed und zap gehts scheinbar tatsächlich mit zapcd() am anlagenanschluss.

 

[udosw]

dann frage ich mich warum es bei mir mit ZapCD am Anlagenanschluss funktioniert.

Hallo,
leider bekomme ich das nicht zum rennen:

[2009-08-18 13:54:11]     -- Executing [346@call-deflect:2] zapCD("Zap/29-1", "0178XXXXXXXX") in new stack
[2009-08-18 13:54:11]     -- Executing [346@call-deflect:3] Progress("Zap/29-1", "") in new stack
[2009-08-18 13:54:11]     -- Executing [346@call-deflect:4] Hangup("Zap/29-1", "") in new stack
[2009-08-18 13:54:11]   == Spawn extension (call-deflect, 346, 4) exited non-zero on 'Zap/29-1'
[2009-08-18 13:54:11]     -- Hungup 'Zap/29-1'
[2009-08-18 13:54:11] 1 Unable to handle return result on switchtype 5!

Das ist an einem Primux mit einer Digium TE205P und Asterisk 1.4.19.1-BRIstuffed-0.4.0-RC1 (Xorcom) und der Dialplan an der Stelle ist nach diesem Schema (aus voip-info.org) gebaut:

exten => 37,1,Wait(0.5) 
 exten => 37,2,ZapCD(<destination-number) 
 exten => 37,3,Progress() 
 exten => 37,4,4,Hangup

Udo