Abbruch bei Anrufen von Anlagenanschlüssen

[jensx]

kennt jemand von euch folgendes Symptom?

Bei 10% der eingehenden Anrufen von Anlagenanschlüssen aus, bricht im Moment der Rufannahme die Verbindung ab. Der darauf i.d.R. wiederholte Anruf funktioniert dann.

Der Effekt tritt definitiv nur mit Anrufen von Anlagenanschlüssen auf. Leider ist nicht genau eingrenzbar seit wann, da wir Hardware gewechselt haben und etwas später auf Bristuff 0.3.0PRE1r umgestiegen sind.

Im BRI_Debug ist zu sehen, dass nach der CONNECT-ACK ein DISCONNECT kommt. Ein intensiv-Debug habe ich noch nicht gemacht, da sehe ich nicht durch.

Aug 15 10:09:55 VERBOSE[29863] logger.c:     -- Executing Dial("Zap/1-1", "SIP/79&SIP/78&SIP/80|40") in new stack
Aug 15 10:09:56 VERBOSE[29863] logger.c:     -- SIP/78-e095 is ringing
Aug 15 10:09:56 DEBUG[29863] chan_zap.c: Requested indication 3 on channel Zap/1-1
Aug 15 10:09:56 VERBOSE[29863] logger.c: 1 > Protocol Discriminator: Q.931 (8)  len=4
Aug 15 10:09:56 VERBOSE[29863] logger.c: 1 > Call Ref: len= 1 (reference 215/0xD7) (Terminator)
Aug 15 10:09:56 VERBOSE[29863] logger.c: 1 > Message type: ALERTING (1)
Aug 15 10:09:59 DEBUG[6629] chan_sip.c: Stopping retransmission on '[email protected]' of Request 102: Match Found
Aug 15 10:10:03 DEBUG[6629] chan_sip.c: Acked pending invite 102
Aug 15 10:10:03 DEBUG[6629] chan_sip.c: Stopping retransmission on '[email protected]' of Request 102: Match Found
Aug 15 10:10:03 DEBUG[6629] chan_sip.c: build_route: Contact hop: 78 <sip:[email protected]:5060>
Aug 15 10:10:03 VERBOSE[29863] logger.c:     -- SIP/78-e095 answered Zap/1-1
Aug 15 10:10:03 DEBUG[29863] chan_sip.c: update_call_counter(80) - decrement call limit counter
Aug 15 10:10:03 DEBUG[29863] chan_sip.c: Acked pending invite 102
Aug 15 10:10:03 DEBUG[29863] chan_sip.c: Stopping retransmission on '[email protected]' of Request 102: Match Found
Aug 15 10:10:03 DEBUG[29863] chan_zap.c: Requested indication -1 on channel Zap/1-1
Aug 15 10:10:03 VERBOSE[29863] logger.c: 1 > Protocol Discriminator: Q.931 (8)  len=11
Aug 15 10:10:03 VERBOSE[29863] logger.c: 1 > Call Ref: len= 1 (reference 215/0xD7) (Terminator)
Aug 15 10:10:03 VERBOSE[29863] logger.c: 1 > Message type: CONNECT (7)
Aug 15 10:10:03 VERBOSE[29863] logger.c: 1 > [Aug 15 10:10:03 VERBOSE[29863] logger.c: 1 > [1 18Aug 15 10:10:03 VERBOSE[29863] logger.c: 1 > [1 181  01Aug 15 10:10:03 VERBO$
Aug 15 10:10:03 VERBOSE[29863] logger.c: 1 > Channel ID (len= 3) [ Ext: 1  IntID: Implicit, Other Spare: 0, Exclusive Dchan: 0
Aug 15 10:10:03 VERBOSE[29863] logger.c: 1 >                        ChanSel: B1 channel
Aug 15 10:10:03 VERBOSE[29863] logger.c: 1                          ]
Aug 15 10:10:03 VERBOSE[29863] logger.c: 1 > [Aug 15 10:10:03 VERBOSE[29863] logger.c: 1 > [1 1eAug 15 10:10:03 VERBOSE[29863] logger.c: 1 > [1 1e1  02Aug 15 10:10:03 VERBO$
Aug 15 10:10:03 VERBOSE[29863] logger.c: 1 > Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user $
Aug 15 10:10:03 VERBOSE[29863] logger.c: 1 >                               Ext: 1  Progress Description: Called equipment is non-ISDN. (2) ]
Aug 15 10:10:03 DEBUG[29863] chan_zap.c: No echo training requested
Aug 15 10:10:03 VERBOSE[6636] logger.c: 1 < Protocol Discriminator: Q.931 (8)  len=4
Aug 15 10:10:03 VERBOSE[6636] logger.c: 1 < Call Ref: len= 1 (reference 87/0x57) (Originator)
Aug 15 10:10:03 VERBOSE[6636] logger.c: 1 < Message type: CONNECT ACKNOWLEDGE (15)
Aug 15 10:10:03 DEBUG[6629] chan_sip.c: Stopping retransmission on '[email protected]' of Request 102: Match Found
Aug 15 10:10:03 DEBUG[6629] chan_sip.c: Stopping retransmission on '[email protected]' of Request 102: Match Not Found
Aug 15 10:10:15 VERBOSE[6636] logger.c: 1 < Protocol Discriminator: Q.931 (8)  len=12
Aug 15 10:10:15 VERBOSE[6636] logger.c: 1 < Call Ref: len= 1 (reference 87/0x57) (Originator)
Aug 15 10:10:15 VERBOSE[6636] logger.c: 1 < Message type: DISCONNECT (69)
Aug 15 10:10:15 VERBOSE[6636] logger.c: 1 < [Aug 15 10:10:15 VERBOSE[6636] logger.c: 1 < [1 08Aug 15 10:10:15 VERBOSE[6636] logger.c: 1 < [1 081  02Aug 15 10:10:15 VERBOSE[$
Aug 15 10:10:15 VERBOSE[6636] logger.c: 1 < Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: User (0)
Aug 15 10:10:15 VERBOSE[6636] logger.c: 1 <                  Ext: 1  Cause: Unknown (16), class = Normal Event (1) ]
Aug 15 10:10:15 VERBOSE[6636] logger.c: 1 < [Aug 15 10:10:15 VERBOSE[6636] logger.c: 1 < [1 1eAug 15 10:10:15 VERBOSE[6636] logger.c: 1 < [1 1e1  02Aug 15 10:10:15 VERBOSE[$
Aug 15 10:10:15 VERBOSE[6636] logger.c: 1 < Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
Aug 15 10:10:15 VERBOSE[6636] logger.c: 1 <                               Ext: 1  Progress Description: Inband information or appropriate pattern now available. (8) ]
Aug 15 10:10:15 VERBOSE[6636] logger.c: 1 -- Processing IE 8 (cs0, Cause)
Aug 15 10:10:15 VERBOSE[6636] logger.c: 1 -- Processing IE 30 (cs0, Progress Indicator)
Aug 15 10:10:15 VERBOSE[6636] logger.c:     -- Channel 0/1, span 1 got hangup request
Aug 15 10:10:15 DEBUG[29863] channel.c: Didn't get a frame from channel: Zap/1-1
Aug 15 10:10:15 DEBUG[29863] channel.c: Bridge stops bridging channels Zap/1-1 and SIP/78-e095

Dem Problem ist halt auch schwer auf die Schliche zu kommen, da ich keinen Anlagenanschluß zum Anrufen habe und der Fehler nicht bei jedem Anruf auftritt.

Danke für jede Hilfe,

Jens

 

[clan]

Wenn ich das richtig sehe besteht die Verbindung für 12 Sekunden und wird dann beendet. Ich finde die Debugmeldung in der vorletzten Zeile interessant, kann es sein, daß der B-Kanal nicht durchgeschaltet wurde und der Anrufer deshalb aufgelegt hat? Hast du zum Vergleich einen Trace von einem gelungenen Anruf?

Intense-Debug auf der ISDN-Leitung wird übrigens nicht viel bringen, da kommen eigentlich nur die L2-Nachrichten dazu. Die Fehler liegen meistens eine Ebene höher.

 

[jensx]

die 12 Sekunden ist aber trotzdem die Leitung tot, also kein Gespräch.

die vorletzte Debug-meldung ist normal, die kommt auch wenn ein normales Gespräch stattfindet nach dem DISCONNECT.

Ich habe mir auch noch mal das Log-file bei normalen Anrufen angeschaut, auch das ist nix anderes zwischen der CONNECT-ACK Bestätigung und dem DISCONNECT zu sehen.

das Problem könnte an der 2. Zeile hier liegen:

Aug 15 10:10:03 DEBUG[6629] chan_sip.c: Stopping retransmission on '[email protected]' of Request 102: Match Found
Aug 15 10:10:03 DEBUG[6629] chan_sip.c: Stopping retransmission on '[email protected]' of Request 102: Match Not Found

aber es ist eben kein Grund ersichtlich.

Leider habe ich aus den SIP-telefonen auch kein anderes Telefon um zu prüfen ob es nur bei ISDN->SIP auftritt. Inzwischen nervt es aber doch erheblich, manche Tage kommt nur jeder 2. Anruf sofort durch und die Kunden merken natürlich irgendwann auch, dass immer bei uns die Leitung zusammenbricht. Beim ersten Mal denken die immer es liegt an der Telekom

 

[multiuse]

kennt jemand von euch folgendes Symptom?

Bei 10% der eingehenden Anrufen von Anlagenanschlüssen aus, bricht im Moment der Rufannahme die Verbindung ab. Der darauf i.d.R. wiederholte Anruf funktioniert dann.

Der Effekt tritt definitiv nur mit Anrufen von Anlagenanschlüssen auf. Leider ist nicht genau eingrenzbar seit wann, da wir Hardware gewechselt haben und etwas später auf Bristuff 0.3.0PRE1r umgestiegen sind.

Ich habe ein ähnliches Problem bei einem Kunden.

Dort verwendete Hardware:
quadBRI von Junghanns sowie eine NoName-HFC-S - Karte (interner S0-Bus), ca. 20 snom360-Phones sowie 2 x Eumex 300IP mit AVM-Firmware als ATAs.

Die quadBRI ist mit 4 AnlagenAnschlüssen beschaltet, ca. 10% der Gespräche brechen plötzlich ab (bei ca. 500 Calls/Tag).

Eine Änderung der Konfiguration im laufenden Betrieb wird nicht gewünscht, also wird gerade der Server nochmal aufgebaut & mit TrixBox 1.11 installiert (Asterisk 1.2.10-BRIstuffed-0.3.0-PRE-1s mit Florz-Patch, Hardware identisch). Allerdings gibt es im Moment noch Probleme mit dem Faxempfang durch Trixbox...

 

[jensx]

Erst mal beruhigt mich ja mal, das auch andere das Problem haben. Ich komm nämlcih überhaut nicht weiter und es nervt.

Bitte versuch doch mal rauszubekommen, ob die abgebrochenen Anrufe von Anlagenanschlüssen kommen. Mit bri debug kann man das ja im log sich mal anschauen auch ohne das etwas am System geändert werden muß. Evtl. könnt j adann doch mal ein zaphfc Profi tiefer rein schauen?

 

[jensx]

Da keine Lösung in sicht war/ist habe ich nun wieder eine 2. HFC-Karte in den Asterisk gebaut und per ISDN-analog Adapter normale Gigaset-DECT-Mobilteile drangehängt. Damit tritt der beschriebene Effekt nicht auf, läßt als die Schlußfolgerung zu, dass das Problem beim Übergang vom ZAP zum SIP liegt.

Was soll's, damit muß man bei OpenSource Software leben wenn man selbst nicht durch den Code debuggen will.

 

[scuba303]

bricht der anruf ab oder kann man einfach eine seite nicht hören? das problem habe ich grade. wobei ich mir nicht sicher bin, ob es an einer leitung zap/4-1 liegt oder ob es tieferliegende probleme gibt.

 

[multiuse]

bricht der anruf ab oder kann man einfach eine seite nicht hören? das problem habe ich grade. wobei ich mir nicht sicher bin, ob es an einer leitung zap/4-1 liegt oder ob es tieferliegende probleme gibt.

Hallo,

ich hatte ein ähnliches Problem - der Junghanns.NET Support riet mir:

...das "one way audio" Problem ist in der Version 0.3.0-PRE-1s neu
hinzugekommen. Bitte weichen Sie auf 0.3.0-PRE-1r aus....

Das habe ich dann auch getan, und die Gesprächsabbrüche und die einseitige Verständigung waren schlagartig verschwunden (und sind es immer noch). Da der Asterisk-Server mit ca. 500 Calls pro Tag relativ gut belastet ist gehe ich davon aus das es tatsächlich der 0.3.0-PRE-1s war der das Problem verursacht hat.

 

[scuba303]

danke. das war die problemlösung..

 

[multiuse]

danke. das war die problemlösung..

Schön das ich auch mal etwas beitragen konnte!

Jetzt warte ich sehnsüchtig auf den neuen BRIstuff damit das Pick-up bei den SNOM's wieder geht....