[Problem] Russisch Roulette bei SIP<->ISDN, Anrufer hört Angerufenen nicht

FilouPBX

Neuer User
Mitglied seit
5 Feb 2013
Beiträge
4
Punkte für Reaktionen
0
Punkte
0
Hallo liebe Gemeinde,

ich komme bei einem fiesen Problem in der SIP - ISDN Kommunikation nicht weiter. Nach etlichen Recherchen sind meine Ideen erschöpft. Die SIP-SIP Kommunikation funktioniert übrigens wunderbar. Ab und zu (in 3 von 4 Anrufen), so berichten mir Kollegen, kommt es zu
  1. keiner Verbindung wenn sie vom Festnetz oder Mobilfunk aus auf ihrem SIP-Client angerufen werden. Besser gesagt, der SIP-Teilnehmer hört den Teilnehmer aus dem PSTN nicht. Umgekehrt scheint es keine Probleme zu geben. Eine! Kollegin X kann weder ins Festnetz telefonieren noch geht es umgekehrt.
  2. Nur eine mittelprächtige Verbindungsqualität macht ihnen allen zu schaffen. Knackgeräusche stören ab und an den Gesprächsfluss. Die Latenz zwischen sagen -> hören ist sehr groß; gefühlte 250ms - 500ms von ISDN zu SIP. Bei SIP-SIP ist alles wunderbar.

Verwendet wird zur Zeit der Jitsi-Client (wegen XMPP und SIP Fähigkeit) in der stable Version 1.0. Andere Clients wurden auch schon getestet. Der Phoner bzw. Phoner Lite ist der einzige Client, der bei Kollegin X funktioniert und mit dem sie sowohl Anrufe von außerhalb entgegennehmen als auch herausrufen kann.

installierte Hardware ist
Pentium 4
ISDN-Karte Digium B410P

installierte Software ist
CentOS 6.3
dahdi-linux-complete-2.6.1+2.6.1
libpri 1.4.14
Asterisk 11.2 rc1
(freepbx - wird zur Zeit nicht benutzt)

Ich habe bereits die Leitung zum Server getestet: ping -l 200 -t liefert <1ms. Bei Vorschlägen und/oder Vermutungen poste ich gerne weitere Ausschnitte aus der Konfig.

dahdi_channels.conf
Code:
; Span 1: B4/0/1 "B4XXP (PCI) Card 0 Span 1" AMI/CCS RED 
context=from-internal; from-pstn
switchtype = euroisdn
signalling = bri_cpe
channel => 1-2
group = 1

; Span 2: B4/0/2 "B4XXP (PCI) Card 0 Span 2" AMI/CCS RED 
context=from-internal; from-pstn
switchtype = euroisdn
signalling = bri_cpe
channel => 4-5
group = 1

; Span 3: B4/0/3 "B4XXP (PCI) Card 0 Span 3" AMI/CCS RED 
context=from-internal
switchtype = euroisdn
signalling = bri_cpe
channel => 7-8
group = 2

; Span 4: B4/0/4 "B4XXP (PCI) Card 0 Span 4" (MASTER) AMI/CCS 
context=from-internal
switchtype = euroisdn
signalling = bri_cpe
channel => 10-11
group = 2

sip.config
Code:
[intern]
context=from-internal
secret=*****
qualify=yes
host=dynamic
caninvite=no
canreinvite=yes
dtmfmode=rfc2833
;allowsubscribe=yes
subscribecontext=from-internal
;insecure=very
bindaddr=0.0.0.0
language=de
directmedia=no
srvlookup=yes
tos=lowdelay
nat=yes
rtptimeout=270
rtpholdtimeout=270
rtpkeepalive=120

[media-codecs]
disallow=all
allow=alaw; Audio
allow=ilbc;  Audio
allow=g729; Audio
allow=gsm;  Audio
allow=g723; Audio
allow=ulaw; Audio
allow=h263;  Video
allow=h261;  Video
allow=h263p; Video
allow=h264;  Video
videosupport=yes

[20](intern,media-codecs) ;Zentrale Einwahl
callerid="######, Zentrale Einwahl"<20>
type=friend
username=#########
mailbox=200

[22](intern,media-codecs) ;#####
callerid="######, Mitarbeiter #####"<22>
type=friend
username=#####
mailbox=220

...

[30] ...
 
Zuletzt bearbeitet:
Die bereits in vielen Foren diskutierten Änderungen der Einstellung canreinvite führen hier zu folgendem:

A sei der Anrufer aus dem PSTN; B sei der Angerufene am SIP-Phone;

canreinvite = nonat
nat = no


B hört klingeln - nach "abnehmen des Hörers": B hört A. A hört nichts.

---------------------
canreinvite = yes
nat = no


B sieht Anruf von A nicht. A hört knacken, danach Besetzzeichen. Auf dem Display des Telefons steht "besetzt".

---------------------
canreinvite = no
nat = no | yes


B sieht Anruf von A nicht. A hört Besetztzeichen. (auf dem Display des Telefons steht "Verbindung abgebaut")
 
Zuletzt bearbeitet:
Task 1 ist gelöst. Die Ursache der einseitigen Verbindung war eine zusätzliche IP im Netzwerkadapter/IPv4 mehrerer Mitarbeiter. Diese IP wurde vor Äonen mal benötigt. Ich denke Asterisk wusste nicht ob es die eingehenden Pakete an die lokale IP-Adresse schicken sollte oder an die zweite 172.x.x.x-er Nummer (oder es hat versucht die 172.x.x.x zu erreichen, was nat. nicht funktionierte). Bei der Aushandlung der Medienströme (RTP) wurde der Parameter a= auf recvonly gesetzt, das heißt:

Zitat (IETF RFC3264 / SDP / 5.1 Unicast Streams)
"If the offerer wishes to only receive media from its peer, it MUST mark the stream as recvonly."
 
Zuletzt bearbeitet:
Task 2 gelöst. Die Einstellung qualify=yes sorgte für den unangenehmen Versatz der Sprache. Wenn aktiviert, prüft Asterisk regelmäßig (Einstellung: qualifyfreq) ob der SIP-Client online ist. Einige Informationen dazu gibt es hier: Asterisk+sip+qualify. Warum es allerdings zu dieser Verzögerung kommt wird dort nicht geklärt. Wenn jemand mehr darüber weiß, bitte gerne posten, ich schau ab und zu in meinen Beitrag.
 
Zuletzt bearbeitet:

Statistik des Forums

Themen
244,696
Beiträge
2,216,701
Mitglieder
371,316
Neuestes Mitglied
realbluethunder
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.