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
51
52
53
54
55
56
57
58
59
60
61
62
63
|
The following modules are in development:
rtpproxy
Generic assignment of RTP proxy for packet forwarding when local and
remote caller is not directly routable. This can include briding when
both source and destination are offsite or on different subnets. This
will enable calls between local users and remote users when either or
both parties are behind NAT. It is assumed a block of rtp ports (and
the sip port) will be "port forwarded" to sipwitch. All proxying is
transparent and hence directly usable for secure calling with ZRTP.
subscriber
This module is meant to eventually offer generic support for premise
routers when used by providers to offer sip/voip service to a subscriber.
It offers rtp proxying and routing based on the assumption that all calls
will be handed off to an external voip provider and automatic rtp
proxy bridging between a subscribers local subnet and an isp. In theory
this would be deployed in an isp supplied premise router to enable a
local user to subscribe a series of local softphone/sip devices with a
remote voip service provider.
scripting
Allows for shell scripts to be executed when things happen in sipwitch,
such as registration/deregistration of sip users.
zeroconf
Publishes sipwitch as a zeroconf sip service. Can only be built with
avahi only so far.
The following additional modules are currently planned:
stun
Stun server plugin module that uses sipwitch registration database for
authentication. For when sipwitch is deployed in public hosting
scenarios. May include an rtp proxy mode to facilate calls between
users who may be behind NAT and also were unable to "stun"...
providers
Will be used to register sipwitch with multiple sip service providers
and manage provider routing rulesets.
routing
Will be used to generate inter-nodal refers when multiple sipwitch
locations are used with each location having a "block" of users &
extension numbers.
gateways
Will be used for future gateway handling and destination routing, rather
than originally planned internal one.
telecenter
Support of hotelling of user id's and telecenter routing with remote
provider. To be used in conjunction with handoff to remote bayonne
server for completing calling card operations and audio prompts.
Telecenter NAT/RTP proxying behavior is similar to subscriber.
forward
For using sipwitch as a front-end "secure" telephone switch with a
backend insecure B2BUA style IP-PBX. All secure stations register
with sipwitch and sipwitch then forwards (re-registers) with the IP-PBX.
All destinations not reachable in the secure domain are referred to
(forwarded to) the insecure IP-PBX to handle.
|
