[GELÖST]: Asterisk API: Problem mit Call Originate

[denny_]

Guten Morgen zusammen.

Ich bin seit mehreren Tagen in der Testphase, dass ich meinen Asterisk mit Java fernsteuern kann.

Ich möchte erreichen, dass mein Asterisk selbstständig eine Verbindung zwischen meinem Telefon und der "Außenwelt" herstellt.

Sprich: Ich gebe über das programmierte Interface eine Nummer ein, Asterisk ruft mein Telefon an, und sobald die Verbindung zu meinem Telefon steht, ruft er die angeforderte Nummer über ISDN nach draußen.

Nun hab ich gesehen, dass es im Asterisk-Manager-Interface (API) eine Application namens "Originate" gibt.
So weit ich in Erfahrung bringen konnte, soll diese Anwendung genau das tun was ich möchte.

Nun stehe ich aber vor folgendem Problem:

Wenn ich im API den Befehl mit folgenden Parametern übergebe:

action: originate
Channel: SIP/13 < ausgehender Channel mit Telefondurchwahl intern (Telefon klingelt auch)
Context: SIP < Context wo externe Wahlregel definiert ist
Exten: ******** < Nummer welche extern gewählt werden soll
Priority: 1

klingelt mein Telefon. Sobald ich abnehme wird der Channel gecancelt und ich bekomme nur ein "Trennen" ins Display.

Als erstes meinte Asterisk er findet keine 's'-Extension im Context "default". (Wobei ich mich frage, warum er überhaupt in den "default" will...)
Dann hab ich versuchshalber einmal diese Extension mit der Wahlregel nach extern erstellt.

s => { Dial( CAPI/ISDN1/${EXTEN} ) };

er sprang in die Extension und wähle:

Starting SIP/13-0000003d at SIP,CAPI/ISDN1/s,1

Das heißt er übergab die Nummer "s" anstatt die gewähle Nummer...

Weißt da jemand von euch Rat, wieso das sein kann?

Grüße denny

EDIT:

Ich hab das ganze jetzt mal umgedreht:

action: originate
Channel: CAPI/ISDN1/(Nummer) < ausgehender Call
Context: SIP < Context für internes Telefon
Exten: 13 < Durchwahl internes Telefon
Priority: 1
Timeout: 30000 < Timeout für Verbindungsherstellung
CallerID: (nummer) < Nummer des internen Telefonanschlusses

Nun verbindet er mich zuerst nach draußen, wenn Gegenstelle abnimmt, wählt er intern.
Phänomen: Er verbindet nicht zu der Exten: 13 sondern macht einen Rundruf an ALLE Telefone.
Exten: 13 wurde testweise in Context SIP UND isdn-in < (Context für einkommende Calls) definiert.

Hat jemand eine bessere Lösung?

(möchte ja eigentlich, dass er ERST das interne Telefon und DANN das externe anwählt!)

 

[rentier-s]

(Wobei ich mich frage, warum er überhaupt in den "default" will...)

Hallo Denny,

er sucht als erstes die Exten@Context, bei Dir also im "SIP". Wenn er die nicht findet, versucht er s@Context, dann s@default.

Wenn Dein Telefon über 13@SIP erreichbar ist, glaube ich nicht, dass Du da auch Deine abgehende Wählregel drin hast, oder?

Im Normalfall hat man ja so etwas:

context SIP {  #intern
  _XX => Dial(SIP/${EXTEN})
}

context abgehend {
  _XX. => Dial(CAPI/ISDN1/${EXTEN})
}

Dann muss das Originate so aussehen:

Action: originate
Channel: SIP/13   (alternativ Local/13@SIP)
Exten: irgendwas
[B]Context: abgehend[/B]
Priority: 1

Svenja

 

[denny_]

Du irrst...

der abgehende Context für Calls nach extern ist ebenfalls in SIP konfiguriert!

Dialplan:

context sip     {

03 =>           {
                Dial(SIP/13,30,Ttm);
                Hangup();
                }

//Externe Anrufe verlangen mindestens 3 Ziffern (z.B.: Notruf)
_XXX! =>        {
                Set(CALLERID(num)=*****57);
                Dial(CAPI/ISDN1/${EXTEN},,Ttr);
                Hangup();
                }
}

Wobei ich schon 03 & 13 probiert hab... beides fehlgeschlagen

Werde zwar bald den abgehenden Context extra setzen und dann nur in SIP includen, aber wollte es erst mal auf die einfache Variante versuchen.

Grüße denny

 

[rentier-s]

Weiß nicht, ob das was ausmacht :noidea:

context sip {

Context: SIP

Ansonsten kann es eigentlich nur ein Tippfehler sein.

03 würde nur mit Local/03@sip klappen, sonst muss es SIP/13 sein.

Btw: mach mal bei dem CAPI Dial die Option t raus ("allow called party to transfer ...").

Svenja

 

[denny_]

sehr seltsames Phänomen :verdaech:

Telnet-Eingabe:

action: originate
Context: sip {
Channel: SIP/13
exten: (Handynummer)
Priority: 1

CLI:

 > Channel SIP/13-00000090 was answered.
    -- Executing [(Handynummer) [D [C@sip:1] Set("SIP/13-00000090", "CALLERID(num)=9258857") in new stack
    -- Executing [(Handynummer) [D [C@sip:2] Dial("SIP/13-00000090", "CAPI/ISDN1/(Handynummer) [D [C||Ttr") in new stack
    -- Called ISDN1/(Handynummer) [D [C
       > ISDN1#02: CAPI INFO 0x34e4: [COLOR="Red"]Invalid information element contents[/COLOR]
  == ISDN1#02: CAPI Hangingup for PLCI=0xdead0000 in state 4
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing [(Handynummer) [D [C@sip:3] Hangup("SIP/13-00000090", "") in new stack
  == Spawn extension (sip, 01709646932 [D [C, 3) exited non-zero on 'SIP/13-00000090'

Nein Handy UND Leitung waren NICHT belegt

genau selbiges wieder im Telnet eingegeben (copy & paste)

2. Ausgabe CLI:

 > Channel SIP/13-00000096 was answered.
  == Starting SIP/13-00000096 at sip {,(Handynummer),1 failed so falling back to exten 's'
  == Starting SIP/13-00000096 at sip {,s,1 still failed so falling back to context 'default'
[Sep 13 11:32:28] WARNING[32695]: pbx.c:2458 __ast_pbx_run: Channel 'SIP/13-00000096' sent into invalid extension 's' in context 'default', but no invalid handler

Ich glaub der will mich veräppeln

 

[rentier-s]

Irgendwie hast Du überall Zeichen drin, die da nicht hingehören.

Executing [(Handynummer) [D [C@sip:2] Dial("SIP/13-00000090", "CAPI/ISDN1/(Handynummer) [D [C||Ttr") in new stack

Context: sip {

== Starting SIP/13-00000096 at sip {,(Handynummer),1 failed so falling back to exten 's'
== Starting SIP/13-00000096 at sip {,s,1 still failed so falling back to context 'default'

Svenja

 

[denny_]

sip {:

Weiß nicht, ob das was ausmacht

Zitat:
context sip {
Zitat:
Context: SIP

damit hat es aber seltsamerweise 1x funktioniert...

woher die anderen Zeichen kommen

Executing [(Handynummer) [COLOR="Red"][D [C[/COLOR]@sip:2] Dial("SIP/13-00000090", "CAPI/ISDN1/(Handynummer) [COLOR="Red"][D [C[/COLOR]||Ttr") in new stack

kann ich dir leider auch nicht sagen. Die standen da auf einmal drin...

ich habe wirklich langsam die Vermutung, dass mein Telnet die Befehle nicht sauber übergibt bzw. Asterisk sie nicht sauber annimmt!
Aber egal ob ich die Befehle über nen Java-Socket oder über Telnet (Linux sowie Windows) schicke immer das selbe Problem...

 

[rentier-s]

context sip {
Context: SIP

Oh, sry, da war ich etwas zu schreibfaul. Ich meinte damit, dass Du in der extensions.ael sip klein, im AMI Befehl aber groß geschrieben hattest. Im AMI muss die { natürlich raus.

Ich glaube Du hast in Deinem Java noch Überreste von Steuerzeichen drin, die man evtl. in Deinem Editor nicht sieht. Lösch den Abschnitt raus und gib ihn nochmal per Hand neu ein, ohne Copy&Paste. An einen Fehler bei der TCP Übertragung zum AMI glaube ich nicht wirklich.

Svenja

 

[denny_]

so Groß-&Kleinschreibung beachten etc... das wär noch ne Möglichkeit. Werd ich gleich mal ausprobieren. ;-)

Die Überreste können eigentlich nicht sein, weil ich mein JAVA errst heute nochmal neu geschrieben hab. Und wenn ich die Befehle per Handeingabe im Telnet mache, ändert sich deswegen leider auch nichts. Ich probiere die Befehle immer auf mehreren Wegen aus.

Aber mom ich schau mal und geb dann Rückmeldung.

 

[denny_]

*strike*

:groesste: < die ;-)

Ok anscheinend unterscheidet der Asterisk selbst auf Groß-/Kleinschreibung.
Denn das Telnet-Protokoll ist da ja normal etwas lässiger.

Auf jeden Fall in folgendem Szenario:

action: originate
Channel: SIP/13
Context: [COLOR="Red"]sip[/COLOR]
exten: (externe Nummer)
Priority: 1

funktioniert es einwandfrei. ;-)

Danke vielmals.

ANMERKUNG:

Schon die kleinsten Schreibfehler im Asterisk führen dazu, dass er die Extension nicht mehr richtig ausführt und in die (bei mir nicht vorhandene xD) Extension 's' im [default] springt.