Probleme mit call file und DISA

[voipalex]

Hallo!

Ich möchte gerne eine Call Back and Through Lösung realisieren. Dafür gibt es mehrere Möglichkeiten und eine läuft bei mir schon. Eine saubere Lösung sollte aber meines Erachtens auf DISA basieren.

Bei der Umsetzung habe ich allerdings ein paar Probleme. Hier mal meine Testkonfiguration:
- SIP Endgerät bt101, das zurückgerufen werden soll (später natürlich ein richtiges Telefon oder Handy)
- der Einfachheit halber, verzichte ich auf die Darstellung des automatischen Rückrufs und arbeite mit einem statischen call file

call file:

Channel: SIP/bt101
MaxRetries: 0
RetryTime: 10
WaitTime: 30
Context: disacontext
Extension: 1234
Priority: 1

Auszug aus sip.conf (es gibt noch einen sipgate Account)

[general]
context=sipin
port=5060
bindaddr=0.0.0.0
srvlookup=yes
disallow=all
allow=ulaw
allow=alaw
allow=g729 ; ich habe eine g729 Lizenz für Asterisk
allow=gsm
allow=g726
language=de
nat=yes
externip = meindyndnsname.dyndns.org

[bt101]
qualify=2000
type=friend
context=disacontext
username=bt101
fromuser=bt101
host=dynamic
secret=geheimespasswort
nat=yes
canreinvite=yes
dtmfmode=rfc2833
incominglimit=1 ; auch mal mit 2 getestet (siehe unten)
disallow=all
allow=g729

Auszug aus der extensions.conf

[disacontext]
exten => 1234,1,DISA(no-password|ausgehendcontext)

Wenn ich nun das call file nach /var/spool/asterisk/outgoing/ verschiebe, dann wird das bt101 angerufen. Ich gehe ran und bekomme ein Freizeichen. Gebe ich 10000 ein (was im hier nicht aufgeführten ausgehendcontext eine Verbindung zur Sipgate-Testnr herstellt), dann kommt nach einer Weile ein dauerhaftes Störgeräusch im Hörer.

Meldungen auf der Konsole:

    -- Attempting call on SIP/bt101 for 1234@disacontext:1 (Retry 1)
       > Channel SIP/bt101-a37e was answered.
    -- Executing DISA("SIP/bt101-a37e", "no-password|ausgehendcontext") in new stack
    -- Attempting call on SIP/bt101 for 1234@disacontext:1 (Retry 1)
May 23 15:30:48 ERROR[17114]: chan_sip.c:1610 update_user_counter: Call from user 'bt101' rejected due to usage limit of 1
May 23 15:30:48 NOTICE[17114]: channel.c:1815 __ast_request_and_dial: Unable to request channel SIP/bt101
May 23 15:30:48 NOTICE[17114]: pbx_spool.c:232 attempt_thread: Call failed to go through, reason 0
May 23 15:30:53 WARNING[17113]: cdr.c:286 ast_cdr_init: CDR already initialized on 'SIP/bt101-a37e'
    -- Executing Dial("SIP/bt101-a37e", "SIP/10000@sipgate|120") in new stack
    -- Called 10000@sipgate
    -- SIP/sipgate-dfdd answered SIP/bt101-a37e
    -- Attempting native bridge of SIP/bt101-a37e and SIP/sipgate-dfdd
  == Spawn extension (jolext, 10000, 1) exited non-zero on 'SIP/bt101-a37e'
May 23 15:31:01 NOTICE[17113]: pbx_spool.c:242 attempt_thread: Call completed to SIP/bt101

Bei den Meldungen auf der Konsole ist bemerkenswert, dass er anscheinend 2x versucht, das bt101 anzurufen (was natürlich scheitert, da incominglimit=1)
Setze ich incominglimit=2, dann klopft es im Telefon an. Wenn ich auflege und das 2. Gespräch annehme, dann kommt das gleiche Störgeräusch.

Ich vermute fast, dass ich einen Bug in Asterisk (evtl. im Call File Handling) gefunden habe. Denn wenn ich das BT101 nehme und 1234 anrufe (und damit ebenfalls im disacontext lande), dann kann ich problemlos im ausgehendcontext telefonieren.

Anregungen, Erklärungen oder Lösungsansätze?

Gruß
Alex

 

[TinTin]

Hi Alex,

der Fehler liegt im Aufbau Deines callfiles, probier es mal genau SO (Reihenfolge beachten):

channel: SIP/bt101
Callerid: test
Context: disacontext
Extension: 1234
MaxRetries: 0
RetryTime: 10
WaitTime: 30
Priority: 1

Gruß,
Tin

 

[voipalex]

Das brachte leider keine Änderung. Ich habs sowohl mit callerid als auch ohne probiert.
Klappt es bei dir?
Ich verwende übrigens Asterisk 1.0.7

 

[TinTin]

Ich habe Deine Version des callfiles getestet und ebenfalls einen zweiten Anruf erhalten und nichts ging. Mit "meiner" Version geht es bei mir.

Die Reihenfolge der Argumente ist wichtig, hast Du alles genau in der Reihenfolge wie ich? (also erst channel, dann callerid, dann context usw.)und hast Du vielleicht noch Kommentare im callfile o.ä. ? Das mag * auch nicht. Groß- Kleinschreibung ist vielleicht auch wichtig...

 

[voipalex]

Ich habe dein Call File 1:1 übernommen und der Fehler bleibt... :-(

 

[TinTin]

Achja... und im disacontext habe ich noch ein Answer vor dem DISA Aufruf und hinterher ein Hangup

[disacontext]
exten => 1234,1,Answer
exten => 1234,2,DISA(no-password|ausgehendcontext)
exten => 1234,3,Hangup
exten => 1234,102,Busy
exten => h,1,Hangup

 

[voipalex]

auch damit funktioniert es nicht...

 

[TinTin]

und nimm in der sip.conf unter [bt101] mal Deinen normalen context, wie sonst auch, nicht context=disacontext , das braucht da nicht rein, vielleicht trägt das auch zu dem Fehler bei.

 

[voipalex]

context Änderung bei bt101 bringt auch nichts...

 

[TinTin]

canreinvite=no (nicht yes) hab ich bei mir noch unter [bt101] und mehr codecs, gerade für DTMF manchmal nicht unwichtig, also allow=ulaw und allow=alaw mal mit dazu schreiben. Mein ausgehendcontext sieht dann so aus:

[ausgehendcontext]
exten => _.,1,SetCallerID(sipgateID)
exten => _.,2,Dial(SIP/${EXTEN}@sipgate,60,r)
exten => _.,3,Congestion
exten => _.,102,Busy
exten => h,1,Hangup
exten => t,1,Hangup

 

[TinTin]

Ich denke mir kommt's jetzt *g* ... Der G729 ist doch der für den man Lizenzen braucht, oder? lass den mal weg...

 

[voipalex]

Ich denke mir kommt's jetzt *g* ... Der G729 ist doch der für den man Lizenzen braucht, oder? lass den mal weg...

Ich hab ne Lizenz...

 

[TinTin]

Vielleicht cached er irgendwie noch eine alte Version vom callfile bei Dir? Langsam gehen mir die Ideen aus, weil hier geht's ja... Schreib doch mal ein komplett neues callfile from scratch mit anderem Dateinamen und boote den Server mal.

Also dann hier nochmal komplett wie es bei mir aussieht und funktioniert:

callfile

channel: SIP/bt101 
Callerid: test 
Context: disacontext 
Extension: 1234 
MaxRetries: 0 
RetryTime: 10 
WaitTime: 30 
Priority: 1

sip.conf

[sipgate]
type=friend
username=555555
host=sipgate.de
secret=xxxxx
fromuser=555555
fromdomain=sipgate.de
nat=no
context=incoming
canreinvite=no
qualify=no
insecure=very
dtmfmode=info
tos=0x18
disallow=all
allow=ulaw
allow=alaw

[bt101]
type=friend
username=bt101
secret=xxxxx
host=dynamic
context=sipgate_out
nat=yes
disallow=all
allow=ulaw
allow=alaw
canreinvite=no
qualify=no

extensions.conf

[disacontext] 
exten => 1234,1,Answer 
exten => 1234,2,DISA(no-password|ausgehendcontext) 
exten => 1234,3,Hangup 
exten => 1234,102,Busy 
exten => h,1,Hangup

[ausgehendcontext] 
exten => _.,1,SetCallerID(555555) 
exten => _.,2,Dial(SIP/${EXTEN}@sipgate,60,r) 
exten => _.,3,Congestion 
exten => _.,102,Busy 
exten => h,1,Hangup 
exten => t,1,Hangup

 

[voipalex]

Ich habe jetzt mal eine richtige Festnetz-Nr anstatt des bt101 eingetragen und siehe da: Es geht. Warum ist mir aber überhaupt nicht klar.

@TinTin:
Erstmal danke für deine Hilfe!
Hast du selbst ein bt101 benutzt oder mit was hast du es getestet?

 

[TinTin]

Gerne
Nein, kein BT101 sondern ein Sipura-2000. Ich denke aber immer noch, dass es am G729 in Verbindung mit dem BT101 liegen könnte... Wenn mir langweilig wird, hole ich mein altes BT101 mal wieder raus und probier's selbst mal damit *g*, zum verkaufen war's mir immer zu schade, bekommt bestimmt mal irgendwann Kult-Status hehe

 

[TinTin]

Also es hat mir ja doch keine Ruhe gelassen... Habe mein altes BT100/101 ausgegraben (natürlich erstmal verzweifelt versucht mich an das Passwort zu erinnern) und angeschlossen. Auch mit diesem hatte ich kein Problem den Dialtone über DISA und ein ordentliches Gespräch zu bekommen. Getestet mit

disallow=all
allow=ulaw
allow=alaw

und auch dieser Codec Reihenfolge (PCMU, PCMA) im BT100/101 Setup; G729 kann ich leider nicht testen.

 

[voipalex]

Ich vermute auch, dass die Codecs Probleme verursachen. Obwohl ich im z.B. im bt101 nur g729 und g726 erlaubt habe, konnte ich im Asterisk beobachten, dass ein SIP channel mit g711 aufgebaut wurde. Sehr komisch.

Die mein eigentlicher Plan (Callback and -Through) aber auf echte Telefone und Handys abzielt, habe ich vorerst keine Lust, mich mit dem alten bt101 rumzuärgern (beim ht286 gab es übrigens das gleiche Problem).

Trotzdem würde ich mich über einen Screenshot deiner Einstellungen des bt101 freuen (um später mal nach dem Fehler zu suchen). Außerdem wäre es interessant zu wissen, was passiert, wenn du ulaw/alaw verbietest.

Gruß
Alex

 

[TinTin]

An meinen settings im BT101 ist nichts besonderes, arbeite natürlich ohne STUN und SIP Port 5074 sowie RTP Port 5004 , die beide auf's BT101 geworfardet sind. Codecs: Als erster PCMU als zweiter PCMA. SendDTMF via Sip Info. Die Page passt schlecht auf einen screenshot, daher in Kurzform.

Wenn ich nur G729 zulasse geht nichts, da ich keine Lizenz habe und Asterisk rummosert, dass er von ULAW nach G729 nicht transferieren kann ist mir auch schleierhaft wieso und wo er überhaupt ulaw noch herholt, habe überall nur G729 allowed.

Also um genau die gleiche Konstellation zu haben, müßte ich mir erstmal eine G729 Lizenz holen...