<param name="tls" value="true"/>
<param name="tls-bind-params" value="transport=tls"/>
<param name="tls-sip-port" value="5061"/>
<param name="tls-version" value="tlsv1.2"/>
<param name="tls-ciphers" value="DEFAULT@SECLEVEL=2"/>FreeSWITCH Click-to-Dial
dial.lua
local api = freeswitch.API();
local destNumber = argv[1];
local sourceNumber = argv[2];
local fsIP = "10.10.0.52";
if (sourceNumber) then
local sourceDialString = "sofia/default/" .. sourceNumber .. "@" .. fsIP;
local reply = api:execute("originate", "{'absolute_codec_string=PCMA',origination_caller_id_number=" .. destNumber .. "}" .. sourceDialString .. " " .. destNumber .. " XML default");
end
Rufaufbau für User 130 an Zielrufnummer 08003301000 initiieren:
fs_cli -x "luarun dial.lua 08003301000 130"apiban.org
Fred Posner hat ein großartiges Projekt ins Leben gerufen, mit dem sich SIP-Traffic von unerwünschten IP-Adressen effektiv blockieren läßt:
Das Projekt setzt auf global verteilte Honeypots, die IP-Adressen von SIP-Angreifern sammeln. Diese werden in einer Datenbank gespeichert und mit Hilfe einer REST-API bereitgestellt.
Es gibt Beispiele zur Integration in Kamailio, Homer, SIP3 sowie einen Open Source Client für iptables.
DTMF inband automatisch aktivieren
|
1 2 3 4 5 6 7 |
<extension name="DTMF inband" continue="true"> <condition field="${switch_r_sdp}" expression="a=rtpmap:(\d+)\stelephone-event/8000" break="never"> <action application="log" data="INFO Caller DTMF capability: RFC2833"/> <anti-action application="log" data="INFO Caller DTMF capability: inband"/> <anti-action application="set" data="execute_on_answer_1=start_dtmf"/> </condition> </extension> |
QoS mit Diffserv und iptables
So werden mit Hilfe von iptables RTP-Streams mit Diffserv-Tags versehen:
|
1 |
iptables -A OUTPUT -t mangle -p udp -m udp --match multiport --sports 14000:15000,16384:32768 -j DSCP --set-dscp-class ef |
In diesem Beispiel werden udp-Pakete aus den Quellports 14000-15000 und 16384-32768 mit dem DCSP-Tag EF (expedited forwarding) markiert.
RTCP Packet Loss und Jitter anzeigen
Zur Fehlersuche im Zusammenhang mit RTP ist RTCP eine große Hilfe.
Wenn auf dem VoIP-System RTCP aktiviert ist, lassen sich mit tshark gezielt Packet Loss und Jitter-Probleme herausfiltern:
|
1 |
tshark -i eth0 -o "rtp.heuristic_rtp: TRUE" -Y 'rtcp.ssrc.fraction >= 1 or rtcp.ssrc.jitter >= 240' -V |
FreeSWITCH mit Deutsche Telekom SIP-Trunk
Beispielkonfiguration für den Betrieb eines SIP-Trunks der Deutschen Telekom an FreeSWITCH 1.6.20:
|
1 2 3 4 5 6 7 8 9 10 |
<gateway name="telekom"> <param name="realm" value="sip-trunk.telekom.de"/> <param name="register-proxy" value="reg.sip-trunk.telekom.de"/> <param name="outbound-proxy" value="reg.sip-trunk.telekom.de"/> <param name="register" value="true"/> <param name="from-user" value="+49xxxxxxxx"/> <param name="username" value="<Zugangsnummer>"/> <param name="password" value="<Passwort>"/> <param name="extension" value="auto_to_user"/> </gateway> |
Patton SmartNode: Deutsche Telekom SIP-Trunk
Dieses Config Snippet zeigt, wie ein Patton SmartNode mit Trinity-Firmware korrekt an einem DeutschlandLAN SIP-Trunk der Deutschen Telekom betrieben wird:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 |
profile voip TELEKOM codec 1 g711alaw64k rx-length 20 tx-length 20 dtmf-relay rtp context cs SWITCH interface sip IF_SIP_TELEKOM bind context sip-gateway GW_SIP_WAN route call dest-table RT_FROM_WAN remote reg.sip-trunk.telekom.de early-disconnect privacy address-translation outgoing-call to-header user-part call host-part fix sip-trunk.telekom.de address-translation outgoing-call request-uri user-part call host-part fix sip-trunk.telekom.de target-param none address-translation outgoing-call identity-header user-part call e164 single-primary host-part fix sip-trunk.telekom.de address-translation incoming-call calling-e164 from-header address-translation incoming-call called-e164 p-called-party-id use profile voip TELEKOM authentication-service AUTH_TELEKOM username <Zugangsnummer> password <Kennwort> location-service LOC_TELEKOM domain 1 sip-trunk.telekom.de match-any-domain identity <Registrierungsrufnummer +49...> alias expression .+ user phone authentication outbound authenticate 1 authentication-service AUTH_TELEKOM username <Zugangsnummer> registration outbound registrar sip-trunk.telekom.de transport-protocol force tcp proxy 1 reg.sip-trunk.telekom.de lifetime 600 register auto flows nat-traversal crlf 55 call outbound proxy 1 reg.sip-trunk.telekom.de transport-protocol force tcp request-uri dynamic-registrar flows call inbound use profile voip TELEKOM |
Patton SmartNode: umgeleiteten ISDN-Anruf an bestimmtes Ziel routen
Wenn ein ankommender Anruf aufgrund einer Rufumleitung (CF) des Anschlusses 030123456789 am SmartNode eintrifft, soll dieser an die Rufnummer 089234567890 an die SIP-PBX geroutet werden.
|
1 2 3 4 5 |
routing-table called-e164 RT_FROM_ISDN route default dest-interface IF_SIP_PBX MT_CF mapping-table calling-redir-e164 to called-e164 MT_CF map 030123456789 to 089234567890 |
Patton SmartNode: Network provided CGPN aus ISDN an SIP-PBX übermitteln
Im ISDN wird neben der vom Anrufer gesetzten Rufnummer (user-provided, not screened) auch die tatsächliche Anschlussrufnummer (network-provided) übermittelt. Diese beiden Rufnummern weichen z.B. voneinander ab, wenn der Anrufer mit clip no screening eine komplett von der Anschlussrufnummer abweichende Rufnummer spooft (in diesem Beispiel 08001234567).
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
SETUP (DSS1 User) [04038090A3] Bearer capability : speech - CCITT circuit mode - 64kBit/s - G.711 A-law [1803A1838B] Channel id : 11 - preferred other interface - is not d-channel - CCITT - b-channel units [6C0C218032313138313136373033] Calling party number : 8001234567 national number - E.164 numbering plan presentation allowed - user provided not screened [6C082183323131383130] Calling party number : 301234567890 national number - E.164 numbering plan presentation allowed - network provided [7007C1323132313231] Called party number : 30567890 subscriber number - E.164 numbering plan [7D029181] High layer compatibility : telephony CCITT |
Mit der nachfolgenden Konfiguration kann ein Patton SmartNode Gateway beide Rufnummern an die SIP-PBX weiterleiten.
|
1 2 3 4 5 6 7 |
interface sip IF_SIP bind context sip-gateway GW_SIP route call dest-table RT_TO_ISDN remote 10.10.10.10 early-disconnect privacy address-translation outgoing-call identity-header user-part call e164 double-primary-first host-part fix isdn;user=phone |
Im SIP-INVITE werden die Rufnummern dann so zugeordnet:
P-Asserted-Identity = ISDN network provided
P-Preferred-Identity = ISDN user provided, not screened
So sieht das Ganze dann im SIP-INVITE aus:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
INVITE sip:030567890@10.10.10.10:5060 SIP/2.0 Via: SIP/2.0/UDP 10.10.10.20:5060;branch=z9hG4bK78ff5ef91a725aa3b Max-Forwards: 70 From: <sip:08001234567@10.10.10.20:5060>;tag=aed58e3281 To: <sip:030567890@10.10.10.10:5060> Call-ID: 10de514fc9ca5984 CSeq: 19829 INVITE Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, INFO, UPDATE, REFER, REGISTER Contact: <sip:08001234567@10.10.10.20:5060;transport=udp> P-Asserted-Identity: <sip:0301234567890@isdn;user=phone> P-Preferred-Identity: <sip:08001234567@isdn;user=phone> Supported: replaces User-Agent: Patton SN4970 4E30VR 00A0BA09D858 R6.10 2018-01-09 H323 RBS SIP M5T SIP Stack/4.2.14.18 Content-Type: application/sdp Content-Length: 185 |