Pascom Cloud Anlage legt bei "extern/nachher" einfach auf!

Support
,
1

Hallo in die Pascom Gemeinde!
Ich verzweifle an einem Problem, welches bis 5.Juli22 nicht existierte bzw. alle Funktionen bestens liefen.
Der Kunde nutzt ein TEAM, das Team hat 3 Mitglieder, die im Abstand von 15s Klingeln angewählt werden. Es ist ein Teamtimeout von 50s definiert, danach sollte (und wurde) extern/nachher ausgeführt werden. Extern/nachher besteht aus einer unbedingten Ansage und danach einer Voicemailbox Ansage auf die Team Mailbox. Das Problem: Nach dem Team timeout 50s wird eine Verbindung aufgebaut und sofort beendet.

Das CLI gibt folgende Meldungen aus:
(einmal Team Timeout 50s - danch Team Timeout 45s)

– Nobody picked up in 10000 ms
== Spawn extension (sub_multidial, s, 9) exited non-zero on ‘Local/106@mdc_multidial-106-000000e9;2’
– Executing [ext@sub_main-203:7] Return(“PJSIP/mdc_trunk_conf-11-0000006c”, “”) in new stack
– Executing [203-dial@mdc_team-6:9] Gosub(“PJSIP/mdc_trunk_conf-11-0000006c”, “sub_suffix-203,ext,1”) in new stack
== Spawn extension (mdc_diallocation, static, 1) exited non-zero on ‘Local/106@mdc_diallocation-000000ea;2’
== Spawn extension (mdc_locallocation-7, 106, 3) exited non-zero on ‘Local/106@mdc_locallocation-7-000000eb;2’
== Spawn extension (mdc_localdevice-19, 106, 4) exited non-zero on ‘Local/106@mdc_localdevice-19-000000ec;2’
– Executing [ext@sub_suffix-203:1] Verbose(“PJSIP/mdc_trunk_conf-11-0000006c”, “1,dialstatus: queuestatus: TIMEOUT”) in new stack
dialstatus: queuestatus: TIMEOUT
– Executing [ext@sub_suffix-203:2] Set(“PJSIP/mdc_trunk_conf-11-0000006c”, “DIALSTATUS=TIMEOUT”) in new stack
– Executing [ext@sub_suffix-203:3] Goto(“PJSIP/mdc_trunk_conf-11-0000006c”, “sub_suffix-action-203,ext,1”) in new stack
– Goto (sub_suffix-action-203,ext,1)
– Executing [ext@sub_suffix-action-203:1] Playback(“PJSIP/mdc_trunk_conf-11-0000006c”, “ueberlast”) in new stack
[Sep 1 10:35:43] NOTICE[686]: res_pjsip_sdp_rtp.c:146 rtp_check_timeout: Disconnecting channel ‘PJSIP/mdc_trunk_conf-11-0000006c’ for lack of audio RTP activity in 51 seconds
– <PJSIP/mdc_trunk_conf-11-0000006c> Playing ‘ueberlast.alaw’ (language ‘de’)
kardiobonn-01cc7b90-2ec5-18ae-3ce4-c69bb8705120CLI>
kardiobonn-01cc7b90-2ec5-18ae-3ce4-c69bb8705120CLI>
kardiobonn-01cc7b90-2ec5-18ae-3ce4-c69bb8705120*CLI>

– PJSIP/zbW45OUPS60258D-0000007f Internal Gosub(mdc_localdevice_predial,team,1) complete GOSUB_RETVAL=
– Called PJSIP/zbW45OUPS60258D
== Using SIP RTP Audio TOS bits 184
== Using SIP RTP Audio CoS mark 5
– Connected line update to Local/106@mdc_localdevice-19-0000010e;2 prevented.
– PJSIP/zbW45OUPS60258D-0000007f is ringing
– Local/106@mdc_localdevice-19-0000010e;1 is ringing
– Nobody picked up in 5000 ms
– Executing [ext@sub_main-203:7] Return(“PJSIP/mdc_trunk_conf-11-0000007b”, “”) in new stack
– Executing [203-dial@mdc_team-6:9] Gosub(“PJSIP/mdc_trunk_conf-11-0000007b”, “sub_suffix-203,ext,1”) in new stack
– Executing [ext@sub_suffix-203:1] Verbose(“PJSIP/mdc_trunk_conf-11-0000007b”, “1,dialstatus: queuestatus: TIMEOUT”) in new stack
dialstatus: queuestatus: TIMEOUT
– Executing [ext@sub_suffix-203:2] Set(“PJSIP/mdc_trunk_conf-11-0000007b”, “DIALSTATUS=TIMEOUT”) in new stack
– Executing [ext@sub_suffix-203:3] Goto(“PJSIP/mdc_trunk_conf-11-0000007b”, “sub_suffix-action-203,ext,1”) in new stack
– Goto (sub_suffix-action-203,ext,1)
– Executing [ext@sub_suffix-action-203:1] Playback(“PJSIP/mdc_trunk_conf-11-0000007b”, “ueberlast”) in new stack
== Spawn extension (sub_multidial, s, 9) exited non-zero on ‘Local/106@mdc_multidial-106-0000010b;2’
== Spawn extension (mdc_diallocation, static, 1) exited non-zero on ‘Local/106@mdc_diallocation-0000010c;2’
== Spawn extension (mdc_locallocation-7, 106, 3) exited non-zero on ‘Local/106@mdc_locallocation-7-0000010d;2’
== Spawn extension (mdc_localdevice-19, 106, 4) exited non-zero on ‘Local/106@mdc_localdevice-19-0000010e;2’
[Sep 1 10:45:10] NOTICE[686]: res_pjsip_sdp_rtp.c:146 rtp_check_timeout: Disconnecting channel ‘PJSIP/mdc_trunk_conf-11-0000007b’ for lack of audio RTP activity in 46 seconds
== Spawn extension (sub_suffix-action-203, ext, 1) exited non-zero on ‘PJSIP/mdc_trunk_conf-11-0000007b’
kardiobonn-01cc7b90-2ec5-18ae-3ce4-c69bb8705120*CLI>
Disconnected from Asterisk server
Asterisk cleanly ending (0).
Executing last minute cleanups

Zum Test nach Geschäftsschluss stelle ich das TeamTimeout auf 15s, dann wird die Ansage wie erwartet abgespielt. Ob die Timeout Zeit der enstcheidende Punkt ist weiß ich nicht, jedoch hat es bis ca. July22 funktioniert.
Ich hoffe jemand hat einen Tipp oder Lösungsansatz für mich.
Vielen Dank und Grüße

2

Hallo @DATAFUNK ,

welches Amt wird hier verwendet? Probiere bitte mal im (extern) vorher des Teams folgendes Inline-Script aus:
Progress()
Das könnte dein Problem lösen.

Grüße,
Steve

3

Hallo Steve,
vielen Dank für den Hinweis zum Script!
Kann es sein, dass das eigentliche Script fehlt?
Progress() kann nicht alles gewesen sein oder?
Verwendet wird TELEKOM Mehrgeräte Anschluss MSN per SIP.
Kein Company Flex oder SIP Trunk.
Beste Grüße

4

Derzeit deutet viel darauf hin, dass der Asterisk sich da nicht ganz korrekt verhält. Progress() ist nur ein Workaround, daher fehlt das nicht wirklich, kann aber in solchen Fällen weiterhelfen.

5

Hi @DATAFUNK,

ja Script ist vermutlich zu hochtrabend dafür, für das was das “Inline Script” macht:
Es wird ein SIP Progress versendet, in dem SDP Informationen enthalten sind, wodurch die SDP Aushandlung abgeschlossen ist und der Asterisk schonmal das Rufzeichen selbst als RTP Stream zum Provider beispielsweise sendet. Das “Script” ist an sich aber so vollständig. Also wirklich nur in den Aktionen (extern) vorher ein Inlinescript hinzufügen und das Progress() als Inhalt einfügen.

Es deutet alles auf einen Asterisk Bug hin, aber bis das auf einem blanken Asterisk nachgestellt wird und dann bei Digium als Bug vorgelegt werden kann und dann auch noch behoben wird, vergeht - so fürchte ich - einiges an Zeit.
Sollte dieses Inline-Script das Problem nicht lösen, gebt bitte Bescheid, damit wir nicht der falschen Fährte folgen.

Grüße,
Steve

6

servus steve
ich habe das problem auch grade bei nem kunden ( Ticket# 5954611)
erst wenn ich das “script” Progress() bei extern vorher mit eintrage, dann gehts… wenn ich aber das timeout extern von 30 auf 25 sec verringere, dann gehts auch… bei 45sec gehts NICHT…
KOMISCH :frowning:
edit: bei unserer anlage GIBTS Das problem aber wohl nicht (gleicher externer provider)
timeout extern 30 + 60 klappt:

image
image912×277 15.7 KB

7

soo wenn ich im amt das hier aktivere:
image

dann gehts ???