[Frage] Include & h-extension

[MaverrickTM]

Guten Abend zusammen,

angenommen im Default Context werden 2 weitere Contexte inkludiert, wovon einer eine h-extension besitzt. Ist es möglich dieses Kontrukt so zu bauen, dass beide weiterhin im default Context inkludiert sind, jedoch die h-extention nicht beim anderen inkludierten Context angewendet wird?

Beispiel - Asterisk 1.8:

[default]
    <...>
    include => outgoing
    include => intern

[outgoing]
    <...>
    exten => h,1,Set(GLOBAL(CurrentLines)=$[${CurrentLines}-1])

[intern]
    exten => _XXX,1,Ringing()
    exten => _XXX,n,Dial(SIP/${EXTEN})

    <...>

In diesem Beispiel würde die Variable nun auch heruntergezählt werden, wenn ein interner Anruf getätigt wird, der durch den internen Context abgehandelt wird. Gibts für solche Fälle eine Lösung?

Schonmal vielen Dank!

 

[rentier-s]

In diesem Beispiel würde die Variable nun auch heruntergezählt werden, wenn ein interner Anruf getätigt wird, der durch den internen Context abgehandelt wird.

Ist das ein Testergebnis oder eine Vermutung? Imho dürfte die h-extension so nämlich gar nicht aufgerufen werden.

Ich würde vor dem Dial eine (vererbbare) Variable setzen und diese im h abfragen.

Für das gewünschte Verhalten wäre die Verwendung von GROUP und GROUP_COUNT übrigens weit besser geeignet.

 

[MaverrickTM]

Das ist leider ein Testergebnis. Meine SIP-Clients hängen im default und beim internem Anruf wird tatsächlich die Variable um eins reduziert.

Ich werd mir GROUP und GROUP_COUNT mal anschauen, danke.

 

[rentier-s]

Hm, wundert mich, dass h überhaupt "included" wird. Ich bin mir halbwegs sicher, dass das früher (<=1.6) nicht ging.

Könntest Du der Wissenschaft halber was ausprobieren? Mach mal eine h-extension in beiden Contexten und schau (zB. mit Noop()), welche jeweils ausgeführt wird bei internen und abgehenden Anrufen.

 

[MaverrickTM]

Es wird die h-ext des ersten inkludierten Contextes verwendet. Die andere kommt nicht zum zuge.

Default-Context

tk01*CLI> dialplan show home
[ Context 'home' created by 'pbx_config' ]
  <...>
  Include =>        'sip_1und1_outgoing'                          [pbx_config]
  Include =>        'intern'                                      [pbx_config]

Intern

tk01*CLI> dialplan show intern
[ Context 'intern' created by 'pbx_config' ]
  'h' =>            1. NoOp(intern)                               [pbx_config]
  <...>

Outgoing

tk01*CLI> dialplan show sip_1und1_outgoing
[ Context 'sip_1und1_outgoing' created by 'pbx_config' ]
  <...>
  'h' =>            1. NoOp(outgoing)                             [pbx_config]
  <...>

Console

-= 7 extensions (29 priorities) in 1 context. =-
  == Using SIP RTP CoS mark 5
    -- Executing [204@home:1] Ringing("SIP/201-0000003d", "") in new stack
    -- Executing [204@home:2] Dial("SIP/201-0000003d", "SIP/204,,xX") in new stack
  == Using SIP RTP CoS mark 5
    -- Called SIP/204
    -- SIP/204-0000003e is ringing
    -- SIP/204-0000003e is ringing
    -- SIP/204-0000003e answered SIP/201-0000003d
    -- Executing [h@home:1] NoOp("SIP/201-0000003d", "outgoing") in new stack
  == Spawn extension (home, 204, 2) exited non-zero on 'SIP/201-0000003d'

Inkludiere ich als erstes Intern und dann Outgoing, dann kommt die h-ext von intern zum Tragen.

  == Using SIP RTP CoS mark 5
    -- Executing [204@home:1] Ringing("SIP/201-0000003f", "") in new stack
    -- Executing [204@home:2] Dial("SIP/201-0000003f", "SIP/204,,xX") in new stack
  == Using SIP RTP CoS mark 5
    -- Called SIP/204
    -- SIP/204-00000040 is ringing
    -- SIP/204-00000040 answered SIP/201-0000003f
    -- Executing [h@home:1] NoOp("SIP/201-0000003f", "intern") in new stack
  == Spawn extension (home, 204, 2) exited non-zero on 'SIP/201-0000003f'

Wenn direkt im default Context eine h-ext benutzt wird, dann ist wie zu erwarten diese dominant.

  == Using SIP RTP CoS mark 5
    -- Executing [204@home:1] Ringing("SIP/201-00000043", "") in new stack
    -- Executing [204@home:2] Dial("SIP/201-00000043", "SIP/204,,xX") in new stack
  == Using SIP RTP CoS mark 5
    -- Called SIP/204
    -- SIP/204-00000044 is ringing
    -- SIP/204-00000044 answered SIP/201-00000043
    -- Executing [h@home:1] NoOp("SIP/201-00000043", "default") in new stack
  == Spawn extension (home, 204, 2) exited non-zero on 'SIP/201-00000043'

 

[MaverrickTM]

Sry. wg. Doppelpost!

Hab mir die beiden Funktionen kurz angeschaut und bin nicht wirklich draus schlau geworden, wie sie mein Problem lösen sollen. Werde nun den Umweg über eine weitere Variable gehen, die die Verbindung klassifiziert ([intern|extern]) und dann mit Bedingung festlegen, dass die globale Variable nur bei extern angefasst werden darf.

@rentier-s

Weisst Du zufällig ob das h include Problem auch unter * v11 besteht?

 

[rentier-s]

Doppelpost? Nach über drei Tagen darf das durchaus so sein.

[outgoing]
exten => _0X.,1,Set(GROUP()=outgoing)

[woauchimmerDudasErgebnisbrauchst]
exten => wasweißich,n,Set(CurrentLines=${GROUP_COUNT(outgoing)})

Der Vorteil daran ist, dass Du Dich eben nicht selbst darum kümmern brauchst, den Zähler zu reduzieren.

Problem würde ich das nicht nennen, das Verhalten entspricht ja der üblichen Dialplanlogik. Insofern wird das wohl bei allen neueren Versionen so sein.
Ich war nur bis jetzt der Meinung, dass (zumindest bis 1.6) nur special extensions aus dem Ursprungs-Context verwendet werden, ich meine wir hatten sogar mal eine Diskussion dazu. Oder war das nur bei Makros? :gruebel:

 

[MaverrickTM]

Der Groschen fiel gerade pfennigweise... (Könnte an der Uhrzeit nach Herrentag liegen...)

Nun verstehe ich wie Du das gemeint hast. Das ist natürlich sehr viel eleganter gelöst, als der Weg via Variable. So muss ich auch nicht versuchen negative Werte abzufangen, falls irgendwas schief geht - was einiges an Komplexität raus nimmt

Ick könnt Dir knuschten! Danke


Wenn ich auf v11 aktualisiere, und es nicht vergesse (ist ja immer sone Sache... xD), werde ich mal testen und berichten.