I'm very very new to the world of VoIP, so please forgive my terminological inaccuracies.
I have just installed ( on to a remote server ) the OpenSIPS software.
I have provisioned a Twilio Elastic SIP Trunk which has it's Origination SIP URI set to the IP address of the OpenSIPS server ( but it prepended with the protocol 'sip:' )
I have two iPhones with some VoIP apps, that allow me to specify Auth Name, Auth Password, Username, Display Name, Domain and SIP Proxy.
In OpenSIPS i have created a domain ( with the IP of my server )
also, i created two users ( on that domain ) and gave them Aliases
of 100 and 101.
The software on the iPhones claims that it has 'registered' with the
OpenSIPS server, so I have to accept that.
I believe that my configuration of the Twilio SIP Trunk is correct, on the
basis that there aren't many settings to set, and they all look correct,
and make some kind of logical sense.
What i cant figure out from here, and not for lack of searching the web,
watching hours of webinars etc, is how do I get OpenSIPS to send outbound
calls through to the Twilio Trunk, and also get the handsets to ring on
incomming calls, and Twilio's SIP Trunk has a Termination SIP URI of xxxxxx.pstn.twilio.com which is ( im guessing ) supposed to be entered somewhere in to OpenSIPS but I cannot see how to configure this.
I'm looking for something that is a guide on how to 'connect' OpenSIPS to the Twilio Elastic Sip Trunking service.
Any help appreciated...
So, I'm guessing you want to set up an OpenSIPS instance which acts both as SIP registrar and basic SBC, by simply forwarding all outgoing traffic to the Twilio SIP trunk.
SIP Registrar
It looks like you've already handled the registrar part of OpenSIPS scripting. You can always generate a basic configuration that handles user registrations with:
make menuconfig
"Generate OpenSIPS script"
"Residential script"
To list the currently registered OpenSIPS users:
opensipsctl ul show
SIP Session Border Controller (basic routing)
- managing outgoing traffic
Here are a few useful scripting mechanisms:
$ru / $rU / $rd variables (management of Entire SIP Request URI / Just username of R-URI / Just domain of R-URI) - do all necessary changes (i.e. force the R-URI to be xxxxxx.pstn.twilio.com...)
$du variable - (management of Outbound Proxy) - this will help us route to the Twilio SIP trunk. Setting a destination URI, then doing t_relay() will simply proxy the current request to the specified destination. For a more advanced routing mechanism (i.e. you need to route to a bunch of trunks), consider using the dispatcher module, which supports using a cached SQL table populated with SIP destinations.
- managing incoming traffic
the registrar module functions should be enough for this (test with lookup() or registered(), then just do t_relay()). They will verify if your iPhones are currently registered on the OpenSIPS server.
Related
I am trying to relay a SIP SUBSCRIBE message from OpenSIPS to my ejabberd server. However ejabberd insists on challenging this with a 407 Proxy Authentication Required response.
I would like to somehow add my OpenSIPs server as a trusted peer on ejabberd - is this possible at all? I've been playing with the acls and various parts of configuration but nothing seems to do the trick.
Pete
This question is very specific to FRITZ!Box 7360. I have the lest firmware installed.
I want to configure a sip account from a provider like Elvero. I tried to follow instructions provided at configuring internet telephone. After configuring I do not see any sip connection attempts reaching the sip server and FRITZ!Box complains that it did not get a response from the server.
This means, I cannot receive and make calls through Elvero. Anyone got successful in connecting FRITZ!Box to an external sip provider?
I'm little bit confused about sip proxy and sip outbound proxy? What is the basic difference between sip proxy and sip outbound proxy? Is it mandatory to use sip outbound proxy along with sip proxy? Can anyone point me out from the below image which one is the sip proxy and outbound proxy?
As your attached picture, it should be:
User Agent: Client
SIP outbound proxies: SIP Proxy port 5060 & SIP Proxy port 5070 when they're receiving incoming request from UA
A sip proxy can be understood as an "outbound proxy" or an "inbound proxy".
Details explanation can be describe as below:
"Pretend you are a SIP User Agent, perhaps a very simple UA that
doesn't even do DNS lookups.
A call coming to you is "inbound".
It may hit your home proxy first, and receive treatment such as being
proxied to you based on your registered contact. This is an "inbound
service", and your home proxy is acting as an "inbound proxy".
Now you want to make a call. Since you're making the call, it is going
"out", or can be called "outbound". You send this call to a proxy,
which looks up the request URI in DNS and sends the call on towards
its destination. This proxy is providing the "outbound service" of DNS
resolution, and is acting as an "outbound proxy" for this call.
On any call there may be any number of inbound and outbound proxies
and services. Some proxies may even provide both sorts for a single
call.
Assume the simple network UA1----P1----P2----UA2
UA1 places a call to UA2."
//refer: https://www.ietf.org/mail-archive/web/sip/current/msg06276.html
SIP Proxy
A SIP proxy server receives a SIP request from a user agent or another
proxy and acts on behalf of the user agent in forwarding or responding
to the request.
Sip Outbound Proxy
An outbound Proxy: A proxy that receives requests from a client, even
though it may not be the server resolved by the Request-URI.
Typically, a SIP user agent is manually configured with an outbound proxy, or
can learn about one through auto-configuration protocols.
Basically they are the same, the only difference, is that SIP Proxy treats requests both for UAC (client) and UAS (server), but SIP Outbound Proxy receives requests from UAC.
And, no, it's not mandatory to use SIP Outbound Proxy along with SIP Proxy.
What about scheme from your image, these are not proxy servers, but are registrar servers which are used to register requests of the users and keep the information from these requests.
I have an application that uses Prosody and XMPP to communicate with Google Talk users. I want the app to be able to communicate with Goole Apps users, but according to this document:
http://www.google.com/support/a/bin/answer.py?hl=en&answer=34143
having Google Apps users talk to any xmpp client outside of #gtalk.com requires creating SRV records.
My question is: How can my app talk to Google Apps users /without/ requiring them to create DNS records for their domain? (This is highly technical and no one does this.)
Is there some way to trick my server into talking to Google's XMPP server instead of looking for a non-existent XMPP endpoint?
This may require a creative solution.. hosts file, firewalls, special DNS settings... anything? Is it possible??
Have your XMPP server configured to talk to a local DNS server that serves up whatever SRV records you want. I suggest dnsmasq, with a configuration like this:
# Never forward plain names (without a dot or domain part)
domain-needed
# Never forward addresses in the non-routed address spaces.
bogus-priv
# A SRV record sending XMPP for the example.com domain to
# xmpp-server.l.google.com port 5269
srv-host=_xmpp-server._tcp.example.com,xmpp-server.l.google.com,5269,5
srv-host=_xmpp-server._tcp.example.com,xmpp-server1.l.google.com,5269,20
srv-host=_xmpp-server._tcp.example.com,xmpp-server2.l.google.com,5269,20
srv-host=_xmpp-server._tcp.example.com,xmpp-server3.l.google.com,5269,20
srv-host=_xmpp-server._tcp.example.com,xmpp-server4.l.google.com,5269,20
Does anyone have an experience or just thoughts about securing MQ TCP
communication channels using stunnel?
I am integration with third party S.W which has MQ support built in but it can not support SSL. So to have some kind of security over the TCP we would like to use stunnel. Does any one have any thoughts how to implement and any best practices
I haven't used stunnel so I'll leave that part of the answer to another responder. With regard to WMQ, keep in mind that this will provide you with data privacy and data integrity over the stunnel link but will not give you channel-level services such as WMQ authentication. True, you will have some level of authentication on the stunnel connection itself, but anyone with a TCP route to the QMgr that does not arrive via stunnel will also be able to start that channel.
Your requirement for security obviously includes data privacy. If it also includes authentication and authorization, you might need to use something like BlockIP2 (from http://mrmq.dk )to filter incoming connections on that channel by IP address to insure they arrive over the stunnel link. Of course, there is nothing to prevent someone at the remote end from specifying any channel name to connect to so if you secure one channel, you need to secure them all - i.e. make sure that SYSTEM.DEF.* and SYSTEM.AUTO.* channels are disabled or that they use SSL and/or an exit to authenticate the inbound connection.
Finally, be aware that if WMQ is configured to accept the ID presented by the client then the connection has full administrative access and that includes remote code execution. To prevent this you must configure all inbound channels (RCVR, RQSTR, CLUSRCVR and SVRCONN) that are not administrative with a low-privileged ID in the channel's MCAUSER. For any channels that are intended for administrators, authenticate these with SSL. (Hopefully your 3rd party SW is an application and not an administrative tool! Any WMQ admin tool must support SSL or else don't use it!)
So by all means use stunnel to secure this link, just be sure to secure the rest of the QMgr or else anyone who can legitimately connect (or even anonymous remote users if you leave MCAUSER blank and aren't using SSL and/or exits) will just bypass the security or disable it.
There's a copy of the IMPACT presentation Hardening WMQ Security at https://t-rob.net/links/ which explains all this in more detail.
Rob - I agree with you. For that only we have MQIPT. Which is much better. For STunnel for MQ i have sloved the problem.
Keys -U need a .pem key (From Key manager you can create .p12 and use open ssl to covert to .PEM).
Client Side: Download and install stunnel have followoling entries in the config file
cert = XXX.pem
client = yes
[MQ]
accept = 1415
connect = DestinationIP:1415
Server Side:
cert = xxx.pem
client = no
[MQ]
accept = 1415
connect = MQIP:1415
Once you do this all you have do is just call the amquputc with the Queue name.