I am attempting to send http request from the tool TRYITJsSIP through kamailio to asterisk, however, kamailio returns an error on tcp_read_req (state 7; bad request, no other serror given). Is there a setting I need to allow http packets to pass through kamailio. Note: It does work when I use a tool like MicroSIP or LinPhone.
Thank you
Browsers (at least modern browsers) in which WebRTC apps execute require, in order to allow sharing audio and video devices, connections with servers to be done in a secure way. In web, you could use of WSS. Asterisk and Kamailio support WSS (WebSockets Secure) as transport for SIP.
It is possible (I have done it) to configure chan_pjsip in Asterisk to use WSS as transport (chan_sip also can be configured in that way, but I have not yet experience in WSS with chan_sip). Kamailio has the WebSocket module that also allows it to manage WSS SIP connections. I have used a fork of JsSIP (SIP.js), but it is completely arguable and you may have your own selection criteria.
Thus, you can connect
Web app WebRTC -> WSS -> Asterisk
or
Web app WebRTC -> WSS -> Kamailio -> UDP -> Asterisk
or, of course, whatever architecture you feel comfortable with. The only thing to have into account is that connections between browser and SIP Proxy are to be done in a secure way (you could use also DTLS-SRTP because Asterisk and Kamailio support it and both are natively supported by WebRTC, but, once again, I have not tested it myself).
Related
I want to open any arbitrary TCP socket on a server, but it's behind a proxy and I can only use a port that is intended for HTTP hosting only. Simply put, what is the most transparent way to wrap such a socket into an HTTP connection? Preferably I would call a *nix program through a shell script in the server that would take care of translating the requests.
I apologize if this was answered before, but I am struggling to find and understand anything.
I ended up going with Chisel, which provides a single binary for both servers and clients, with features like authentication and reverse port forwarding. For instance:
chisel server
will run an HTTP server in $PORT or 8080, and
chisel client server.com 4567:123
connects to server.com and maps the remote port 123 into the local port 4567.
Other solutions are still welcome, particularly if they involve more transparency, frequently preinstalled tools like netcat, and if they also provide support for other protocols like UDP.
i'm having a problem with my app, on a certain situation.
We have a java server with jetty webserver embedded, and an air app on the client side.
It is working properly but on a single situation of a certain customer.
They have a private network that is not administrated by them (and has little chances of being changed as request). So, the only port they allow are 80 and 443.
The communications between the server and the client are through websockets and http.
The "online" check is made through http and, then, we use websockets to notify the client in order to start communication between them.
The thing is, in this situation, the "online" state works properly and any communication send by the client (forced), as it goes through http, gets to the server but, when the server communicates with the client, using websockets, it doesn't work.
We are using wireshark to check the communications: On a working setup, when the client app starts, a websocket is shown on wireshark, on the server side (registering the client on the server). And, after that, websockets that are only used from server to the client, don't show also.
What can be the problem? The port 80? (the same happens with 443 on that network).
Can it be a proxy/firewall that are blocking ws:// messages?
I've read somewhere that wss:// (encripted websockets) would work?
Thanks for your help.
Edit, so, I tried with https and wss communication and the same thing happens.. no websocket is set between the client and server (registering the client on the server).
This situation is happening for http on the customer network. On my test network, it works on http/ws but not with https/wss..
There are many firewalls and gateways out "in the wild" that do not understand the whole WebSocket HTTP/1.1 GET -> UPGRADE -> WebSocket mechanism.
There are several broken firewall implementations will attempt to interpret the WebSocket framing as improper content for HTTP/1.1 (which is a bad reading of the HTTP/1.1 spec) and start to muck with it.
The types of firewalls that inspect/filter/analyze the request/response contents are the ones that seem most susceptible.
I would check that the hardware (or software) that they are using to firewall their network is both compliant and upgraded to support WebSocket RFC-6455.
I want a cloud machine to send a message to a machine behind a corporate NAT / Firewall.
My idea is to install on the corporate machine a client which sends a long HTTP request to the cloud machine and when the cloud has a message it returns the response.
I thought I invented the wheel until I read about "http tunneling" (is this what I am doing?).
I also read that some firewalls block non html traffic even if it is on http.
So what is my chance to make it work?
I have also read that skype uses a more sophisticated machanism.
Is it because my idea does not work or because their idea is faster?
I can compromise on speed now - which approach works and easy to implement?
I know you'd like to do it with TCP/HTTP,
but the way I'd do it is use UDP to
NAT 'hole punch', thus establishing a UDP channel,
and then use UDP packets sent over that
channel as the signaling mechanism...
These may (or may not) be useful or relevant:
http://en.wikipedia.org/wiki/STUN
http://en.wikipedia.org/wiki/Hole_punching
http://en.wikipedia.org/wiki/UDP_hole_punching
http://en.wikipedia.org/wiki/TCP_hole_punching
Also -- if you really have to use HTTP, you could
simply issue a new HTTP request every X seconds...
HTTP Polling, if you will...
If they block non html on port 80, you could try port 443. Unless there is a SSL "man in the middle" proxy (unlikely), you'd be ok.
IIRC skype uses port hopping, so basically you'll need an algorithm to find an unfiltered (by brute force with intelligent guesses) port that you can connect to.
At the moment I have an existing application which basically consists of a desktop GUI and a TCP server. The client connects to the server, and the server notifies the client if something interesting happens.
Now I'm supposed to replace the desktop GUI by a web GUI, and I'm wondering if I have to rewrite the server to send http packets instead of tcp packets or if I can somehow use some sort of proxy to grab the tcp packets and forward them to the web client?
Do I need some sort of comet server?
If you can make your client ask something like "Whats new pal?" to your server from time to time you can start implementing HTTP server emulator over TCP - its fun and easy process. And you could have any web based GUI.
You can just add to your TCP responds Http headers - itll probably do=)
So I mean HTTP is just a TCP with some headers like shown in here.
You should probably install fiddler and monitor some http requests/ responses you normally do on the web and you'll get how to turn your TCP server into http emulator=)
If you want keep sockets based approche use flash (there is some socket api) or silverlight (there is socket API and you can go for NetTcpBinding or Duplexbinding something like that - it would provide you with ability to receive messages from server when server wants you to receive them (server pushes messages))
So probably you should tall us which back end you plan to use so we could recomend to you something more usefull.
I've written a Flash (Flex) client connecting to a back-end server to exchange data.
I've also written my server from scratch, and it serves two purposes:
(1) Web (HTTP) Server- By default listens on port 80
(2) Socket/Application- Server - By default listens on port 443
Just FYI, both servers run in the same process space, for convenience reasons. They are not expected to handle massive loads, so I'm fine with that.
As soon as the Flash client is served to the browser from the HTTP socket, the client attempts to open an XMLSocket to the Socket/Application server.
I now want to implement HTTP tunneling, so that my client can connect to the Application server even if the user is behind a firewall. I do not want any external servers involved (proxies etc.) - simply use the servers I already have.
My questions:
(1) Is it better to use port 443 for that? (does it better fool firewalls?)
(2) As far as I can see, what I am required to do, is just ensure that my actual application data is simply encapsulated in an HTTP structure (preceded by a dummy HTTP header), both from the client and server sides. Is that so or am I missing anything here?
(3) Do I need to keep hiding/encapsulating my data every message I send through the socket, or can I just encapsulate the first message when opening the connection?
Thanks in advance guys!
Fuzz
Don't reinvent the wheel - use remoting via AMF protocol. AMF an HTTP-based binary format that performs serialization between ActionScript (MXML) and server side languages. Technically, this is HTTP tunneling.
Adobe offers BlazeDS (open source) and LCDS (commercial) implementations of AMF for AS/Java, but there are third-party implementations of AMF for AS/PHP, AS/Python, AS/Ruby, AS/.Net.
BTW, AMF is an open source format.