Gelöst: Ansagen von z.B. Mobilfunkprovidern nicht zu hören

[tjareson]

Hallo,

leider habe ich bis jetzt noch nichts eindeutiges zu dem Thema finden können, darum hier meine Problemstellung.
Nutze Asterisk 1.4.13. auf debian 2.6.18 mit mISDN 1.1.6 mit HFC Karte nach extern, interne Teilnehmer über SIP.

Die Konfiguration läuft seit Jahren stabil. Was bislang nie funktioniert hat, ist, dass ich bei Anwahl von intern an externe bspw. Mobiltelefonummer Ansagen von den Mobilfunkbetreibern hören kann. (z.B. Teilnehmer nicht erreichbar, wenn Handy aus und keine Box) Es wird mir als interner SIP-Teilnehmer immer nur das Freizeichen vorgespielt. Bei Anruf vom Handy oder Skype auf die gleiche Zielrufnummer höre ich dann die Originalansage vom Mobilfunkanbieter. Das ist natürlich dumm, da man nie so richtig weiss, ob der andere nicht dran geht oder sein Handy vielleicht einfach nicht eingeschaltet hat.

Habe versucht mit diversen Parametern von misdn.conf zu experimentieren, leider beziehen diese sich bei näherem Hinsehen eher auf die Art und Weise wie eingehende Anrufe mit Signalisierung vor Verbindungsaufbau gehandhabt werden.

Vielleicht suche ich auch irgendwie an der falschen Ecke und muß die interne SIP-Signalisierung an den SIP-Telefonen ändern/abschalten?
Haben andere auch Asterisk per mISDN angebunden - hört irgendeiner die Originalansagen von Mobilfunkbetreibern oder einfach nur Freizeichen?

Beste Grüße.
Tjareson

 

[jobisoft]

Das ist eine Vermutung, weil ich *glaube* das ich das Problem auch mal hatte. Probiers es aus, wenn es nicht hilft, schade.

Also, du wählst mit deinem Telefon eine Nummer, dazwischen sitzt aber der asterisk, so dass es im Grunde zwei Verbindungen sind. Wenn du asterisk einen externen Dial ausführen lässt, dann werden die beiden Channel erst dann zusammengeführt, wenn abgehoben wird. Bis dahin signalisiert dir dein VoIP-Phone oder dein ATA das Klingeln (du bist noch nicht im asterisk "drinn")

Wenn du aber VOR dem externen dial ein Answer machst, dann nimmt asterisk den Telefon-Channel schon an und dann hörst du die asterisk-signalisierung, bzw dass was auf dem channel reinkommt.

Bei den Mobilfunkern ist es möglich etwas zu hören, obwohl der Anruf nicht angenommen wurde, und genau die Sachen dürftest du dann nicht hören.

Probiers mal aus, würde mich auch interessieren, ob es das war.

EDIT: Und natürlich darfst du den Dial nicht mit der r-Option machen

 

[tjareson]

Probiere ich nachher mal aus. Was ich dabei aber nicht verstehe, woher Answer() dann weiss, welchen channel es "beantworten" soll. Zu dem Zeitpunkt ist doch noch gar nicht festgelegt mit welchem Trunk ich den Dial-Befehl parametrisiere. Könnte ISDN sein, könnte aber beispielsweise auch SIP sein.

Du hörst aber die Ansagen des Mobilfunkproviders, wenn z.B. Handy aus und keine Box geschaltet ist? Das sagt ja schon mal, dass es irgendwie gehen muß...

 

[jobisoft]

Was ich dabei aber nicht verstehe, woher Answer() dann weiss, welchen channel es "beantworten" soll. Zu dem Zeitpunkt ist doch noch gar nicht festgelegt mit welchem Trunk ich den Dial-Befehl parametrisiere.

Es beantwortet DEINEN Channel, mit dem du den asterisk angerufen hast.

Benutzt du einen ATA oder ein VoIP-phone? Dann kann ich ne kleine Skizze machen.

 

[tjareson]

Aber ich rufe doch Asterisk gar nicht an, sondern führe ein von Asterisk abgehendes Gespräch zu beispielsweise einem Mobiltelefon.

Oder meinst Du ein zusätzliches Answer() im dialplan innerhalb des context der bspw. gerade für ausgehende Anrufe genutzt wird?
Spätestens wenn dial() Signalisierungen Richtung Endgerät sendet, müsste doch zwischen herauswählendem Endgerät und Asterisk eigentlich eine Verbindung hergestellt sein.

 

[jobisoft]

Leider hast du nicht beantwortet, was für ein Telefon du hast.

Ich nehme jetzt einfach mal an, du hast ein normales analog telefon in einen ATA gesteckt - dieser ATA hat Zugangsdaten, mit denen er sich an deinem asterisk registriert (hast du in der sip.conf definiert), dazu gehört auch ein context, in dem alle Gespräche zunächst landen, die von deinem ATA/Telefon initiert werden.

Von diesem context aus wird nun durch deine extension.conf entschieden, ob das ein internes oder externes Gespräch ist ... d.h. bei externen Gesprächen kommst du in deinem Dialplan irgendwann zu dem DIAL, der dann die von dir gewünschte externe Nummer anruft.

Während dieser ganzen Zeit bist du doch schon auf deinem asterisk! Es besteht also bereits ein Channel ("Telefon-Channel") - der DIAL nach extern baut einen ZWEITEN Channel auf ("Externen-Channel"). Und sobald der externe Anschluss abhebt, werden die beiden Channel zusammenge"bridged".

Da du aber den Telefon-Channel noch nicht per Answer angenommen hast, "hängt" dein Anruf noch im ATA (dort hast du ja die Nummer gewählt) und dein ATA signalisiert deinem Telefon "ringing" und zwar bis der Channel angenommen wird. Und derzeit wird er erst durch das Bridging angenommen, also erst wenn der gegenüber tatsächlich abhebt.

Jetzt kannst du aber dem asterisk durch einen ANSWER anweisen, den Telefon-Channel schon vor dem externen DIAL anzunehmen, dann wird das deinem ATA mitgeteilt und du bist dann wirklich schon auf dem asterisk und der asterisk übernimmt die Signalisierung von ringing. Und sobald ein Ton auf dem externen Channel reinkommt, kannst du das dann schon höhren, weil asterisk das direkt weitergibt.

Ich hoffe das war jetzt verständlicher. Poste doch mal deine extensions.conf

Edit:

Oder meinst Du ein zusätzliches Answer() im dialplan innerhalb des context der bspw. gerade für ausgehende Anrufe genutzt wird?

Jep, genau das!

 

[tjareson]

Ja, das ist mir im Prinzip schon klar. Die Verwendung von zwei Kanälen
Endgerät<->asterisk<->Zielteilnehmer kann man ja auch auf der Konsole ganz gut sehen, entsprechendes verbose-setting vorausgesetzt.
Endgeräte benutze ich alles möglich, analog über ATA, SNOM und Cisco.

Konnte die Lösung auch gerade mal remote zumindest für meinen Call-Through-Context finden und auch gleich testen. War (peinlich) wie schon oben erwähnt, einfach nur das Ausschalten der Signalisierung im Dial() (also kein r Parameter). Funktioniert ausgehend für SIP und mISDN gleichermaßen. Hat sich dann also erledigt, das ganze...
Hätte schwören können, dass ich das vor Monaten auch schon mal ausprobiert habe.