wir haben ein ziemlich hartnäckiges Problem mit unserem Asterisk-Server und versuchen, es zu lösen. Ich hoffe, dass jemand mit mehr Wissen als ich helfen kann.
Wir verwenden Asterisk 1.8.23.0 auf Centos 6.4 und unsere Telefone und der Asterisk-Server befinden sich innerhalb einer Firewall und unsere VoIP-Dienstanbieter außerhalb. Die Firewall wird von einem externen Unternehmen eingerichtet und verwaltet.
Wir haben derzeit zwei VoIP-Dienstanbieter, A, der den Großteil unseres eingehenden und gesamten ausgehenden Datenverkehrs abwickelt, und , Bder einen Teil unseres eingehenden Datenverkehrs abwickelt, der über ein externes IVR an unser Callcenter weitergeleitet wird.
Bei einem kürzlich durchgeführten Sicherheitsaudit wurde uns mitgeteilt, dass unser gesamter VoIP-Verkehr über eine Firewall laufen sollte. Es wurde entschieden, dass wir dies in zwei Phasen tun sollten.
In der ersten Phase wird der eingehende Datenverkehr, den wir empfangen, durch Beine Firewall geleitet, und in Phase zwei wird der eingehende und ausgehende Datenverkehr Aebenfalls durch die Firewall geleitet. Derzeit stecken wir in Phase eins fest.
Zunächst haben wir versucht, externipund localnetim [general]Abschnitt unserer sip.confDatei festzulegen, aber dadurch wurde der VoIP-Verkehr bei unserem primären VoIP-Dienstanbieter unterbrochen . Daher haben wir versucht, sie im spezifischen Eintrag in unserer Datei für unseren sekundären VoIP-Dienstanbieter Afestzulegen , und zwar wie folgt:sip.confB
[A]
type=friend
disallow=all
allow=alaw
allow=g729
context=fromneotel
host=aaa.aaaa.aaa.aaa
insecure=port,invite
nat=no
directmedia=no
[B]
type=friend
disallow=all
allow=g711
allow=g729
allow=alaw
context=fromis1
host=bbb.bbb.bbb.bbb
insecure=port,invite
nat=yes
directmedia=no
externip=ccc.ccc.ccc.ccc
localnet=192.68.20.0/255.255.252.0
wobei aaa.aaa.aaa.aaadie IP von ist A
und bbb.bbb.bbb.bbbdie IP von ist B
und ccc.ccc.ccc.cccdie externe IP der Firewall ist.
Mit diesen Einstellungen kann das Callcenter Anrufe über das IVR entgegennehmen. Sobald die Anrufe verbunden sind, kann der externe Anrufer den Callcenter-Agenten hören, der Callcenter-Agent kann den Anrufer jedoch nicht hören.
Unser VoIP-Dienstanbieter teilt uns mit, dass ihm in der 200 OK SIPAntwort ccc.ccc.ccc.cccdes SDP-Teils die IP-Adresse mitgeteilt wird, ddd.ddd.ddd.dddan die die Medien gesendet werden sollen.
ddd.ddd.ddd.dddist die IP unseres Asterisk-Servers, Bmit dem wir normalerweise eine Verbindung herstellen, wenn wir nicht versuchen, Datenverkehr durch die Firewall zu leiten. Dies sind die Informationen, die wir von ihnen erhalten:
Via: SIP/2.0/UDP bbb.bbb.bbb.bbb:5060;branch=z9hG4bKmm63qe00d8ogcio100k0.1;received=bbb.bbb.bbb.bbb
From: "Anonymous"<sip:<originating number from IVR>@bbb.bbb.bbb.bbb:5060;user=phone>;tag=1641833502-1377756054727-
To: "<call centre number>"<sip:<call centre number>@ccc.ccc.ccc.ccc:5060>;tag=as43201e45
Call-ID: [email protected]
CSeq: 609518180 INVITE
Server: Asterisk PBX 1.8.23.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:<call centre number>@ccc.ccc.ccc.ccc>
Content-Type: application/sdp
Content-Length: 260
v=0
o=root 1148542603 1148542603 IN IP4 ddd.ddd.ddd.ddd
s=Asterisk PBX 1.8.23.0
c=IN IP4 ddd.ddd.ddd.ddd
t=0 0
m=audio 11064 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
laut Bunserem sekundären VoIP-Dienstanbieter ist dies die Leitung, die das Problem verursacht:o=root 1148542603 1148542603 IN IP4 ddd.ddd.ddd.ddd
eee.eee.eee.eeeist eine IP-Adresse, die ich nicht kenne und über die ich nichts weiß.
Jede Hilfe wird sehr geschätzt.
Antwort1
Anrufe ohne oder nur in eine Richtung übertragenes Audio sind ein häufiges Problem bei der NAT-Nutzung von VOIP. Offensichtlich haben Sie die Ursache des Problems bereits gefunden: Die Pakete, die die Sprache übertragen, werden an die falsche Adresse gesendet.
Ich würde zunächst bei den Leuten nachfragen, die Ihre Firewall warten. Wenn die Firewall ihr Geld wert ist, können sie zweifellos etwas tun, um das Problem zu lösen oder die weitere Diagnose zu erleichtern.
Andernfalls fragen Sie Ihren Anbieter, ob er IAX2-Leitungen unterstützt. IAX2 hat nicht die NATing-Probleme von SIP.
Viel Glück.