I have setup Kamailio with websocket module. When I register with sipML5 its going well. But returns 488 Not Acceptable Here when I trying to call.
488 means: Some aspect of the session description or the Request-URI is not acceptable, or Codec issue. I try check response SIP when called Method INVITE it has PCMU/8000 & PCMA/8000.
I think it's not a Codec issue *CMIIW. Is it possible I have the wrong config for sipML5?
I'm using RTPProxy and coTurn for TURN Server
Make sure IP addresses located in SDP is correct and also you should give a permission for IP addresses.
Related
Is it possible to send a HTTP message to client via browser by typing
http://CLIENT_IP:PORT/MESSAGE
http://192.168.1.1:7777/HELLO
If so could you give me some link to such project or example code ?
Yes, it is, provided you have a http server listening on port 7777 of host 192.168.1.1 that will get your message and do something with it.
Yes, you will get the message as the route or path in the server. The specific variable will vary depending on the language and framework you’re using.
I am running Rethinkdb on a server that lays behind cloudflare. I cannot make connection with my server when using my hostname. (I can access other stuff on my server so i am almost sure the problem doesn't lies there)
I am also able to connect using my ip directly (without adding a cert to the .connect function of rethinkdb client)
I do use Nginx and my client is in java
What i have tried:
Using custom set ports (that were said to be open on cloudflare)
trying proxying location to certain port
Using a cert (Rethink client side)
I couldn't find any information about Rethinkdb behind CloudFlare, so i am open to any suggestions
If i need to post more information please ask, i'm not sure what i should share...
This is not a RethinkDB issue. Cloudflare only supports specific ports, as spelled out here:
https://support.cloudflare.com/hc/en-us/articles/200169156-Which-ports-will-Cloudflare-work-with-
80
8080
8880
2052
2082
2086
2095
And all traffic must be HTTP sessions. RethinkDB communicates via raw TCP sockets. You cannot run it behind Cloudflare.
I know that port 554 (typically RTSP) is open at a certain IP address. I'd like to be able to determine:
Is this really an RTSP server?
Is it possible to access the video stream without authenticating?
I'd also like to do this in as lightweight a fashion as possible. I don't need to access the video stream.
After looking through the RTSP spec I realized that I could simply open a TCP socket and send the following commands:
OPTIONS * RTSP/1.0<CRLF>
CSeq: 1<CRLF>
When I tried this against many servers I found that a handful responded with
RTSP/1.0 200 OK
CSeq: 1
<a bunch of other stuff>
This is to be expected. However, most requests that I made timed out. This leads me to believe that these resources require authentication or I'm doing something fundamentally wrong.
I'm guessing that most servers will respond with a 401 if authentication is required, so I'm probably doing something wrong. Any ideas?
Please refer to RFC2326 of the RTSP protocol: RFC2326
D.1.2 Authentication-enabled
In order to access media presentations from RTSP servers that
require authentication, the client MUST additionally be able to do
the following:
* recognize the 401 status code;
* parse and include the WWW-Authenticate header;
* implement Basic Authentication and Digest Authentication.
When I use display filter for HTTP it shows only HTTP packets when HTTP message is on standard port i.e. on port 80. But, when message is not using standard port, then display filter not works for HTTP and I need to filter for TCP and then need to find out HTTP packets manually.
I want to know why this happen? Is it standard behavior or I am doing (or expecting) it wrongly.
Thanks.
I had to enable the HTTP protocol by doing the following:
"Analyze -> Enabled Protocols"
This solution was for version 1.12.2 (and disabled by default in
version 2.0.2) but should work for any variant of version 1 and 2.
If you have HTTP not on its usual port, you can use the "Analyze -> Decode As" tool in Wireshark to tell it to treat all traffic on this port as a certain protocol.
The well-known port for HTTP is port 80. If you're looking at traffic on a different port Wireshark would normally expect traffic to be in the form for whatever service normally uses that port (if any). It has no way to know that traffic on, say, port 1080 is actually HTTP. This is not a bug, but a limitation of the way you are trying to use TCP
I am using version 1.10.2 and it will classify any port as HTTP as long as it sees HTTP data in it.
I have web application that runs on Tomcat (and gets HTTP requests) and some other backend standalone application that gets only TCP. For some reasons, I can use outside only port 8080. So, I need to get all TCP requests (from outside) to port 8080 and forward HTTP ones to web application on Tomcat and all TCP pure requests (that are not HTTP) - to standalone application. Internal forwarding could be done to any port, e.g. 8181 on Tomcat and 8282 on standalone application. Is it possible to setup such configuration? How it could be done?
Thanks in advance.
TCP and HTTP are protocols in different networking stack layer. If you want to use some application to filter HTTP requests, your application should deal with Application-Layer information, not Network-Layer(like TCP/UDP).
I don't see how this can be possible generally. You could look packet-by-packet, but the middle of an http body can be arbitary so you can't just look at the data of each packet
If any particular client will send you either http or general TCP but not both, can you do this by source-IP address? Do you know the addresses of either the servers that will send you http requests or the ones that will send you TCP requests?
If you don't know the source IPs, you could heuristically look at the first packet from some previously unknown IP and see if it looks like http, then tag that address as containing http traffic.
What is the content/format ot the TCP communication? Is there any pattern you can detect in that?
Y
Perhaps you could do something like this using iptables + L7 filter. Of course this will only work if you run Linux on your box. Also I don't know how recently l7 filter project has been updated.
Java servlet technology is not limited to Http. The servlet interface lets you read in the incoming input stream via ServletRequest.getInputStream(). So you can create an implementation of Servlet interface and map it in web.xml and you are all set to receive any TCP traffic.
Once you have the read the input stream to sniff the content you will want to forward HTTP requests to an HttpServlet. To do this you will need to make sure that the input stream you pass on is positioned at the very beginning of the input.
EDIT: On reading your question once again, I noticed that you don't plan to expose the Tomcat directly on external port as I originally thought. If you are willing to make the tomcat listen on the external port, you can try the approach described above