Early B3: Release Cause 102 nach Ansage größer 16 sekunden

[Emaleth]

Hallo noch mal,

um mein gestriges Thema noch mal aufzunehmen und das Problem genauer zu spezifizieren, hier noch mal ein neuer Thread, da ich denke, dass das Problem in erster Linie an Early B3 und dem Verhalten von Asterisk beim Abspielen von kostenfreien Tarifansagen liegt.

Wir haben herausgefunden, dass wir zwar in der Lage sind Early-B3 Ansagen zu spielen, dass jedoch immer nach etwas mehr als Sekunden mit Release Cause 102 abgebrochen wird:

Cause No. 102 - recovery on timer expiry [Q.850] This cause indicates that a procedure has been initiated by the expiration of a timer in association with error handling procedures.

Nach Rückfrage beim Provider haben wir für die kostenfreie Ansage von dessen Seite sogar 2 Minuten Zeit. Darum befürchten wir, dass es am Asterisk liegt bzw. wie der mit Early-B3 umgeht.

Das Testfile tt-monkey kann ich noch abspielen und danach weitergehen im Dialplan, aber wenn man ein File abspielt, das eine Sekunde länger geht, dann hat man schon das Problem...

exten => _11951.,1,Progress()
exten => _11951.,n,NoOp(${STRFTIME(${EPOCH},,%Y.%m.%d-%H:%M:%S)} Startzeit)
exten => _11951.,n,Playback(tt-monkeys,noanswer)
exten => _11951.,n,NoOp(${STRFTIME(${EPOCH},,%Y.%m.%d-%H:%M:%S)}

*snief* Gibt es denn Optionen für die zapata.conf oder so, wo man auch noch mal einen Timeout für diese Geschichte setzen kann, oder irgendeine andere Variable für den
Dialplan? Irgendwie muss ich dem Provider ja den Progress oder eine Art Keep-alive schicken, dass ich den Call zwar angenommen habe, aber verzögere, oder so ähnlich...


LG, Sabine

 

[alfhh]

Hallo, hast du eventuell noch ein paar Infos über Hardware und Provider? Geht es hier um ISDN oder IP Telefonie? Mal so aus dem Bauch heraus würde ich sagen, das die "Vermittlungsstelle" von dir keine Rückmeldung bekommt, dass der Ruf angenommen wird. Daher das recht kurze Timeout. Vielleicht hilft es, ein "Ringing" oder "Progress" zu senden, bevor die Early Media Ansage abgespielt wird. Liste doch bitte Hardware und Provider in einer Signatur auf.

Bis denn,
Alf

 

[Emaleth]

Hallo Alf,

ich schicke natürlich ein Progress, das habe ich oben korrigiert, hatte ich irgendwie vergessen mit anzugeben und eine falsche Version meiner extensions.conf angegeben.

Die Karte ist von Sangoma:

Sangoma Technologies Corp. A104X

Ich rufe von einem ganz normalen Telefon über die DTAG auf meinem Asterisk-Server an.

Die Logs sehen wie folgt aus:

a) kurzer Anruf mit anschliessender Weiterleitung zum Application-Server

sip-02*CLI>
    -- Accepting overlap call from '06102xxxxxx' to '11951xxxxxx' on channel 0/3, span 1
    -- Starting simple switch on 'Zap/3-1'
    -- Executing [11951xxxxxx@dtms:1] Progress("Zap/3-1", "") in new stack
    -- Executing [11951xxxxxx@dtms:2] NoOp("Zap/3-1", "2008.09.19-12:45:47 Startzeit") in new stack
    -- Executing [11951xxxxxx@dtms:3] Playback("Zap/3-1", "tt-monkeys|noanswer") in new stack
    -- <Zap/3-1> Playing 'tt-monkeys' (language 'en')
    -- Executing [11951xxxxxx@dtms:4] NoOp("Zap/3-1", "2008.09.19-12:46:03 Ansagezeit1") in new stack
    -- Executing [11951xxxxxx@dtms:5] NoOp("Zap/3-1", "2008.09.19-12:46:03 Endzeit") in new stack
    -- Executing [11951xxxxxx@dtms:6] Dial("Zap/3-1", "SIP/11951xxxxxx@lion") in new stack
    -- Called 11951xxxxxx@lion
    -- SIP/lion-0084efd0 answered Zap/3-1
  == Spawn extension (dtms, 11951xxxxxx, 6) exited non-zero on 'Zap/3-1'
    -- Hungup 'Zap/3-1'

b)längerer Anruf mit Disconnect, Release Cause 102

  -- Accepting overlap call from '06102xxxxxx' to '119519xxxxxx' on channel 0/2, span 4
    -- Starting simple switch on 'Zap/95-1'
    -- Executing [119519xxxxxx@dtms:1] Progress("Zap/95-1", "") in new stack
    -- Executing [119519xxxxxx@dtms:2] NoOp("Zap/95-1", "2008.09.19-12:44:58 Startzeit") in new stack
    -- Executing [119519xxxxxx@dtms:3] Playback("Zap/95-1", "conf-adminmenu|noanswer") in new stack
    -- <Zap/95-1> Playing 'conf-adminmenu' (language 'en')
    -- Channel 0/2, span 4 got hangup request, cause 102
  == Spawn extension (dtms, 119519xxxxxx, 3) exited non-zero on 'Zap/95-1'
    -- Hungup 'Zap/95-1'

Ich weiß allerdings nicht, ob Progress() auch noch bestimmte Werte haben kann. Mir sagte jemand man müsste Progress 1, 2 oder 8 schicken? Wie geht das mit dem Progress() Befehl?

Ich schaue mal, ob ich ein isdn-Trace anwerfen kann.

LG und danke schon mal, Sabine

 

[Emaleth]

Hier mein IDSN-Trace:

< Protocol Discriminator: Q.931 (8)  len=52
< Call Ref: len= 2 (reference 24976/0x6190) (Originator)
< Message type: SETUP (5)
< [04 03 80 90 a3]
< Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
<                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
<                                User information layer 1: A-Law (35)
< [18 03 a9 83 84]
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit  PRI  Spare: 0  Exclusive  Dchan: 0
<                        ChanSel: As indicated in following octets
<                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
<                       Ext: 1  Channel: 4 ]
< [6c 0d 21 81 36 31 30 32 38 38 32 39 33 31 32]
< Calling Number (len=15) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
<                           Presentation: Presentation permitted, user number passed network screening (1)  '6102xxxxxx' ]
< [70 10 81 31 31 39 35 31 39 30 30 35 31 30 30 39 33 39]
< Called Number (len=18) [ Ext: 1  TON: Unknown Number Type (0)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)  '11951xxxxxx' ]
< [7d 02 91 81]
< IE: High-layer Compatibility (len = 4)
-- Making new call for cr 24976
-- Processing Q.931 Call Setup
-- Processing IE 4 (cs0, Bearer Capability)
-- Processing IE 24 (cs0, Channel Identification)
-- Processing IE 108 (cs0, Calling Party Number)
-- Processing IE 112 (cs0, Called Party Number)
-- Processing IE 125 (cs0, High-layer Compatibility)
q931.c:3504 q931_receive: call 24976 on channel 4 enters state 6 (Call Present)
q931.c:2821 q931_setup_ack: call 24976 on channel 4 enters state 25 (Overlap Receiving)
> Protocol Discriminator: Q.931 (8)  len=14
> Call Ref: len= 2 (reference 24976/0x6190) (Terminator)
> Message type: SETUP ACKNOWLEDGE (13)
> [18 03 a9 83 84]
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit  PRI  Spare: 0  Exclusive  Dchan: 0
>                        ChanSel: As indicated in following octets
>                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
>                       Ext: 1  Channel: 4 ]
> [1e 02 81 82]
> Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: Private network serving the local user (1)
>                               Ext: 1  Progress Description: Called equipment is non-ISDN. (2) ]
    -- Accepting overlap call from '06102xxxxxx' to '11951xxxxxx' on channel 0/4, span 1
    -- Starting simple switch on 'Zap/4-1'
    -- Executing [11951xxxxxx@dtms:1] Progress("Zap/4-1", "") in new stack
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 24976/0x6190) (Terminator)
> Message type: PROGRESS (3)
> [1e 02 81 88]
> Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: Private network serving the local user (1)
>                               Ext: 1  Progress Description: Inband information or appropriate pattern now available. (8) ]
    -- Executing [11951xxxxxx@dtms:2] NoOp("Zap/4-1", "2008.09.19-12:58:39 Startzeit") in new stack
    -- Executing [11951xxxxxx@dtms:3] Playback("Zap/4-1", "conf-adminmenu|noanswer") in new stack
    -- <Zap/4-1> Playing 'conf-adminmenu' (language 'en')
< Protocol Discriminator: Q.931 (8)  len=13
< Call Ref: len= 2 (reference 24976/0x6190) (Originator)
< Message type: DISCONNECT (69)
< [08 02 82 e6]
< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Public network serving the local user (2)
<                  Ext: 1  Cause: Recover on timer expiry (102), class = Protocol Error (e.g. unknown message) (6) ]
< [1e 02 81 82]
< Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: Private network serving the local user (1)
<                               Ext: 1  Progress Description: Called equipment is non-ISDN. (2) ]
-- Processing IE 8 (cs0, Cause)
-- Processing IE 30 (cs0, Progress Indicator)
q931.c:3779 q931_receive: call 24976 on channel 4 enters state 12 (Disconnect Indication)
    -- Channel 0/4, span 1 got hangup request, cause 102
  == Spawn extension (dtms, 11951xxxxxx, 3) exited non-zero on 'Zap/4-1'
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication, peerstate Disconnect Request
q931.c:2920 q931_release: call 24976 on channel 4 enters state 19 (Release Request)
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 24976/0x6190) (Terminator)
> Message type: RELEASE (77)
> [08 02 81 e6]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Recover on timer expiry (102), class = Protocol Error (e.g. unknown message) (6) ]
    -- Hungup 'Zap/4-1'
< Protocol Discriminator: Q.931 (8)  len=5
< Call Ref: len= 2 (reference 24976/0x6190) (Originator)
< Message type: RELEASE COMPLETE (90)

 

[Emaleth]

Noch etwas wichtiges, laut zapta.conf ist priindication = inband, was wohl, wenn ich das richtig sehe so sein muß um das Early-B3 überhaupt nutzen zu können.

Außerdem ist es wohl laut meinen Trace so, dass ich Progress Indicator 0 schicke und angeblich muß ich 8 schicken. Wie sage ich das dem Asterisk?

 

[Burmann]

Wenn ich das richtig sehe werden 2 "Progress Indicator" Nachrichten verschickt, einamal das der User n"nicht ISDN" ist und einmal dass "Inband information" o.ä. jetzt da sind...

 

[alfhh]

Da muss ich doch mal nachfragen, du kannst (offensichtlich) Early Media bzw Early B3 Connect von einem T-Com Anlagenanschluss senden? Oder hängt der Asterisk an einem anderen Provider? Ich würde an deiner Stelle mal ohne Early Media testen wie lange es dauert, wenn du einen ankommenden Anruf nicht auf eine Nebenstelle sendest, bis das Amt einen Timeout signalisiert. Ich habe den Verdacht, das du der Vermittlung nicht mitteilst, das du den Anruf verarbeitest.
Bei Sip macht man das mit "ringing". Leider kenne ich mich mit den Sangoma Karten nicht aus, könnte aber mal an meinem Anlagenanschluss (T-Com) schauen wie lange der bis zum Timeout braucht.

Bye,
Alf

 

[Emaleth]

Hallo Alf,

an dem Asterisk-Server hängen E1en, auf denen Early B3 aktiviert ist und theoretisch sollte ich dieses Feature nun auch nutzen können und mit Progress() sollte der Asterisk auch eigentlich der Vermittlung den ISDN Progress Indicator mitteilen, sprich damit sollte mitgeteilt werden, dass der Anruf verarbeitet wird und das scheint irgendwie nicht richtig bzw nicht zu funktionieren.

LG, Sabine

 

[hehol]

Hallo Sabine,

Du hast noch nicht verraten, welche Versionen von Asterisk und Zaptel Du verwendest. Außerdem wäre wichtig zu wissen, ob Du noch irgendwelche Patches in Asterisk benutzt (bristuff oder Patches einer Linux-Distribution).

Außerdem ist es wohl laut meinen Trace so, dass ich Progress Indicator 0 schicke und angeblich muß ich 8 schicken. Wie sage ich das dem Asterisk?

Direkt kannst Du das Asterisk nicht sagen. Dem D-Kanal Trace nach zu urteilen vermute ich auch eher wie Alf, daß das Amt den Anruf beendet, weil zu lange "nichts" passiert. Bitte schalte mal overlapdial in der zapata.conf aus und teste, wie lange es dann dauert, bis das Amt einen Timeout signalisiert.

Henning

 

[Emaleth]

Hallo Henning,

ich nutze:

asterisk-1.4.20.1
asterisk-addons-1.4.7
libpri-1.4.5
zaptel-1.4.12.1
wanpipe-3.2.7.1

Nach dem Stand jetzt weiß ich, dass ich sogar den richtigen Progress Indicator, nämlich 8 schicke, der steht nur leider im falschen ISDN-Message Type. Neuer Post von mir dazu im richtigen Board unter bristuff:

http://www.ip-phone-forum.de/showthread.php?t=176047

Ich weiß dass der Anruf beendet wird, weil zu lange nichts passiert. Das liegt aber nun wohl daran, dass der Progress im falschen ISDN Message Type geschickt wird und so die Vermittlungsstelle eben denkt, dass da nichts mehr kommt, was ja nicht sein soll. Sprich callprogress scheint nicht zu funktionieren, bzw. nicht richtig.

Das mit dem overlapdial kann ich zwar ausschalten zum Testen, wenn ich nächste Woche wieder im Büro bin, bzw. ich habe es an meinen Kollegen weitergeben, aber tendenziell benötige ich schon auch overlapdial für andere Sachen.

LG und dancke schon mal für die Hilfe.

Sabine

 

[Emaleth]

Also Update:

Mit Änderung der zapata.conf-> overlapdial=no funktioniert es. Leider benötigen wir overlapdial=yes, da wir DDIs verwenden möchten. Von daher sehe ich jetzt erst einmal keine Lösung für das Problem.

Oder doch?

LG, Sabine