ISDN/Capi Gespräche brechen ab

[mgs]

Hallo alle,

habe eine (fast) funktionierende Anlage mit MDK 10.2,Bristuff neueste.
Der Rechner ist ein P4 (HT=off), mit einer AVM C4 + HFC-S.
Kernel ist ein 2.6.11 an einem Anlagenanschluss via PTP
Ansich funzt das ja alles ganz prima - bis auf, das ausgehende Gespräche von SIP auf ISDN allesamt nach ca. 3min abbrechen/abgebrochen werden - einfach so. Asterisk meldet einfach CAPI Hangup und das wars, andere Sachen sind nicht betroffen und laufen reibungslos.
Komischerweise besteht selbige Problematik auch unter Suse - dachte zunächst wer weiss, wies da ausschaut, aber 1:1 dassselbe, ist da irgendwo ein Timeout oder ähnliches ? Benutze Grandstreams als IP's.
Bin echt ratlos.


Viele Grüsse

 

[Hupe]

Also, ob das problem wirklich ein Capi-Problem ist? Sieh doch mal im syslog nach (ung ggf in /var/log/asterisk/messages). Könnte es sein, dass irgendwo in deinem netz (z.B. auf dem Asterisk) ne Firewall ist, oder so. Ich würde auch mal einen "sip debug" laufen lassen, um die entsprechenden Sip-Meldungen lesen zu können, die ausgegeben werden, wenn das Problem auftritt. Du könntest mal deinen (anonymisierte) sip.conf und capi.conf posten. Außerdem wären die Versionen von Asterisk und chan_capi interessant.

 

[mgs]

ok, also als chan_capi habe ich die 0.3.5 als auch die neueste getestet - beides dieselbe Problematik. In den Logs tauchen keine Meldungen oder so auf. Asterisk kommt aus der aktuellen Bristuff, hatte aber schon andere Versionen + RPM ausgetestet, alles dasselbe. Meine Vermutung war ja zunächst, das das mit der SMP/HT Sache zu tun haben könnte,
daraufhin so ziemlich alles ausprobiert - ausser einen 2.4-er Kernel :cry:


hier die sip conf für das SIP Telefon, die globals sind im Prinzip Standard.

[xx]
type=friend
username=xx
regexten=xxxx
callerid="xx" <xx>
secret=xx
host=dynamic
nat=no
canreinvite=yes
dtmfmode=rfc2833
disallow=all
allow=ulaw
allow=alaw
context=xxx

Die capi.conf :

[general]
nationalprefix=0
internationalprefix=00
rxgain=0.8
txgain=0.8

[interfaces]

isdnmode=ptp
msn=xxxxx
incomingmsn=*
context=xxxxx
group=1
accountcode=
softdtmf=1
controller=1,2,3,4
devices => 8

sip debug zum Abbruchzeitpunkt, du scheinst recht zu haben :

SIP/2.0 200 OK
Via: SIP/2.0/UDP ***;branch=***;rport
From: <sip:***@***>;tag=***
To: "***" <sip:***@****>;tag=***
Call-ID: ***@***
CSeq: 102 BYE
User-Agent: Grandstream GXP2000 1.0.1.9
Contact: <sip:***@***>
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK
Supported: replaces, timer, 100rel
Content-Length: 0


11 headers, 0 lines
Message is BYE
Destroying call '***@***'

Aber die Frage ist, warum tut er das ?

 

[Hupe]

Naja, hätte mir am liebsten die gesaamte sip.conf gewünscht (also inclusive des General-Bereiches, da da ja viele Einstellungen vorgenommen werden), aber Versuch doch mal folgendes:
Füge in die sip.conf für den(die) Sip-Clients folgende Zeile neu ein:

qualify=yes

sonst würde ich mal in deienm GS-Adapter nachsehen. Um auszuschliessen, dass es an dem GS-Adapter liegt, kannst Du ja auch mal ein Softphone benutzen!

 

[mgs]

Ok, hier die generals aus der SIP conf. Alles andere ist in der erstmal off.
Der Eintrag qualify=yes hat keinen Effekt gehabt, habe das eben nochmal gemessen, es sind exakte 3 min, dann ist ende. Im GS Interface gibts was mit Session default = 180, aber das habe ich alles schon geändert usw. das änderte am Verhalten leider nichts.


[general]
context=default
port=5060
bindaddr=0.0.0.0
disallow=all
allow=ulaw
allow=alaw
musicclass=default
rtptimeout=600
rtpholdtimeout=3000
useragent=Asterisk PBX
nat=no

 

[mgs]

Beim wegmachen etwas übersehen:

Das BYE Signal kommt vom Asterisk Server.
zunächst Stopt er z.B. Musiconhold (wenns gerad läuft, dann kommt Capihangup) und im sip debug kommt dann das SIP Packet : 102 BYE

Vorher (vor abbruch) sehen die Pakete so aus:

CSeq: 102 OPTIONS
User-Agent: Grandstream GXP2000 1.0.1.9
Session-Expires: 9999;refresher=uac
Min-SE: 9999

 

[mgs]

So nun das Capi Debug eines solchen Abbruchs, ich hab immernoch irgendwie den Verdacht irgendwo ist n Timeout = 180 im ISDN Sub oder wo auch immer, das ist immer so verdächtig bei 3 min. jedesmal.
Vieleicht hilft ja das debug, die Reason = 0x3302 ist doch Protokoll Fehler Layer 2 ??

CAPI Debugging Enabled
-- Executing Answer("SIP/**-1320", "") in new stack
-- Executing Dial("SIP/**-1320", "CAPI/contr3/b****") in new stack
-- data = contr3/b*****
-- capi request controller = 3
-- creating pipe for PLCI=0
== CAPI Call CAPI/contr3/b****-2 with B3 (pres=0x00)
CONNECT_REQ ID=001 #0x2111 LEN=0060
Controller/PLCI/NCCI = 0x3
CIPValue = 0x10
CalledPartyNumber = <80>******
CallingPartyNumber = <00 80 22>*****<22> <3c>*****<3e>
CalledPartySubaddress = default
CallingPartySubaddress = default
BProtocol
B1protocol = 0x1
B2protocol = 0x1
B3protocol = 0x0
B1configuration = default
B2configuration = default
B3configuration = default
BC = default
LLC = default
HLC = default
AdditionalInfo
BChannelinformation = <00 00>
Keypadfacility = default
Useruserdata = default
Facilitydataarray = default

-- Called contr3/b*****
CONNECT_CONF ID=001 #0x2111 LEN=0014
Controller/PLCI/NCCI = 0x103
Info = 0x0

== received CONNECT_CONF PLCI = 0x103 INFO = 0
INFO_IND ID=001 #0x21cd LEN=0019
Controller/PLCI/NCCI = 0x103
InfoNumber = 0x8
InfoElement = <82 e4 98>l

INFO_RESP ID=001 #0x21cd LEN=0012
Controller/PLCI/NCCI = 0x103

== info element CAUSE 82 e4
INFO_IND ID=001 #0x21ce LEN=0015
Controller/PLCI/NCCI = 0x103
InfoNumber = 0x800d
InfoElement = default

INFO_RESP ID=001 #0x21ce LEN=0012
Controller/PLCI/NCCI = 0x103

== info element SETUP ACK
INFO_IND ID=001 #0x21cf LEN=0016
Controller/PLCI/NCCI = 0x103
InfoNumber = 0x18
InfoElement = <89>

INFO_RESP ID=001 #0x21cf LEN=0012
Controller/PLCI/NCCI = 0x103

== info element CHANNEL IDENTIFIKATION 89
INFO_IND ID=001 #0x21d0 LEN=0015
Controller/PLCI/NCCI = 0x103
InfoNumber = 0x8002
InfoElement = default

INFO_RESP ID=001 #0x21d0 LEN=0012
Controller/PLCI/NCCI = 0x103

== info element CALL PROCEEDING
INFO_IND ID=001 #0x21d1 LEN=0015
Controller/PLCI/NCCI = 0x103
InfoNumber = 0x8001
InfoElement = default

INFO_RESP ID=001 #0x21d1 LEN=0012
Controller/PLCI/NCCI = 0x103

== info element ALERTING
INFO_IND ID=001 #0x21d2 LEN=0017
Controller/PLCI/NCCI = 0x103
InfoNumber = 0x1e
InfoElement = <82 88>

INFO_RESP ID=001 #0x21d2 LEN=0012
Controller/PLCI/NCCI = 0x103

== info element PI 82 88
In-band information available
CONNECT_B3_REQ ID=001 #0x2112 LEN=0013
Controller/PLCI/NCCI = 0x103
NCPI = default

-- CAPI/contr3/b*****-2 is ringing
CONNECT_B3_CONF ID=001 #0x2112 LEN=0014
Controller/PLCI/NCCI = 0x10103
Info = 0x0

CONNECT_B3_ACTIVE_IND ID=001 #0x21d3 LEN=0013
Controller/PLCI/NCCI = 0x10103
NCPI = default

CONNECT_B3_ACTIVE_RESP ID=001 #0x21d3 LEN=0012
Controller/PLCI/NCCI = 0x10103

INFO_IND ID=001 #0x2247 LEN=0020
Controller/PLCI/NCCI = 0x103
InfoNumber = 0x29
InfoElement = <05 08 12 0d 1a>

INFO_RESP ID=001 #0x2247 LEN=0012
Controller/PLCI/NCCI = 0x103

== info element Date/Time 05/08/18 13:26
CONNECT_ACTIVE_IND ID=001 #0x2248 LEN=0015
Controller/PLCI/NCCI = 0x103
ConnectedNumber = default
ConnectedSubaddress = default
LLC = default

CONNECT_ACTIVE_RESP ID=001 #0x2248 LEN=0012
Controller/PLCI/NCCI = 0x103

-- CAPI/contr3/b*****-2 answered SIP/***-1320
INFO_IND ID=001 #0x224a LEN=0037
Controller/PLCI/NCCI = 0x103
InfoNumber = 0x1c
InfoElement = <91 a1 13 02 02 26 b8 02 01 22>0<0a a1 05>0<03 02 01 01 82 01 00>

INFO_RESP ID=001 #0x224a LEN=0012
Controller/PLCI/NCCI = 0x103

== info element FACILITY
INFO_IND ID=001 #0x224b LEN=0019
Controller/PLCI/NCCI = 0x103
InfoNumber = 0x4000
InfoElement = <01 00 00 00>

INFO_RESP ID=001 #0x224b LEN=0012
Controller/PLCI/NCCI = 0x103

== CAPI: unhandled INFO_IND 0x4000 (PLCI=0x103)
-- Started music on hold, class 'default', on CAPI/contr3/b*****-2
INFO_IND ID=001 #0x33df LEN=0037
Controller/PLCI/NCCI = 0x103
InfoNumber = 0x1c
InfoElement = <91 a1 13 02 02 26 c2 02 01 22>0<0a a1 05>0<03 02 01 02 82 01 00>

INFO_RESP ID=001 #0x33df LEN=0012
Controller/PLCI/NCCI = 0x103

== info element FACILITY
INFO_IND ID=001 #0x33e0 LEN=0019
Controller/PLCI/NCCI = 0x103
InfoNumber = 0x4000
InfoElement = <02 00 00 00>

INFO_RESP ID=001 #0x33e0 LEN=0012
Controller/PLCI/NCCI = 0x103

== CAPI: unhandled INFO_IND 0x4000 (PLCI=0x103)


---> und zum Abbruch dann :


DISCONNECT_B3_IND ID=001 #0x44e3 LEN=0015
Controller/PLCI/NCCI = 0x10103
Reason_B3 = 0x3301
NCPI = default

DISCONNECT_B3_RESP ID=001 #0x44e3 LEN=0012
Controller/PLCI/NCCI = 0x10103

DISCONNECT_IND ID=001 #0x44e4 LEN=0014
Controller/PLCI/NCCI = 0x103
Reason = 0x3302

DISCONNECT_RESP ID=001 #0x44e4 LEN=0012
Controller/PLCI/NCCI = 0x103

-- Stopped music on hold on CAPI/contr3/b6*****-2
-- CAPI Hangingup
-- removed pipe for PLCI = 0x103

 

[armincm]

DISCONNECT_B3_IND ID=001 #0x44e3 LEN=0015
Controller/PLCI/NCCI = 0x10103
Reason_B3 = 0x3301
NCPI = default

DISCONNECT_B3_RESP ID=001 #0x44e3 LEN=0012
Controller/PLCI/NCCI = 0x10103

DISCONNECT_IND ID=001 #0x44e4 LEN=0014
Controller/PLCI/NCCI = 0x103
Reason = 0x3302

Also der Abbruch kommt von Deiner CAPI/ISDN Gegenstelle. Das hat nichts mit SIP zu tun.
Der ReasonB3=0x3301 sagt
" Protocol error layer 1 (broken line or B-channel removed by signalling protocol)"

Warum das passiert, kann ich allerdings nicht sagen, nur dass es nicht an der Asterisk-Seite liegt.

Armin

 

[mgs]

hmm, das komische ist, habe mal andere Zielnummern genommen auch Handy . Alles dasselbe, nach exakt 3 min bricht die Verbindung ab.

 

[mgs]

leider bisher dazu weiter nichts gefunden, ist noch jemand mit ner C4 + Anlagenanschluss da, der zumindest mal grob sagt welches sys usw. er genommen hat, damit ich evtl. die Fehlerquelle lokalisieren kann ?
Ich habe mal intern via PTMP Mode getestet - dabei treten die Verbindungsabbrüche nicht auf. Betrifft also nur den PTP Mode am Anlagenanschluss für jedes nach aussen gehende Gespräch egal wohin. :cry: