I have a freeswitch based PBX that has been working fine. I was using Skype connect as a SIP provider and I have had no difficulty making and receiving calls using this. Also, no difficulty with internal local-local calls.
I have just changed my sip trunk provider to voip-unlimited (based in the UK) and updated my sip profile accordingly. I can receive calls fine with the new provider, but when I make a call, the other party can hear me, but I cannot hear them. I do not get a ringing tone when I dial out (the remote party's phone rings, he answers the call, he hears me, but I cannot hear him).
I have ports 5060 and 5080 open to both UDP and TCP traffic and the router also supports PnP. I am uncertain if it is a firewall issue but certainly no problems were experienced with Skype connect previously.
the best thing would be to run a packet sniffer (tcpdump or wireshark) and see what's going on when the call is set up.
It might be:
codec negotiation problem
firewall settings problem
NAT traversal problem
Ok, got it sorted.
I set the PBX back to using Skype Connect. I ran wireshark and could see the connection getting established over TCP and the RTP packets flowing to and from the PBX using UDP.
I then switched over to the new SIP trunk provider. I again ran wireshark, could see the connection getting established over TCP, but this time incoming RTP packets were not present.
I checked the router's firewall and all seemed fine. Nothing in the log files etc. I still suspected the router however. Upon googling for my router model (a Netgear WNR2200) I came across a setting to disable the SIP ALG (Application Level Gateway). I did this (disabled) it and problem solved. By the looks of things, the SIP ALG feature of the router was interfering with and breaking SIP. It is supposed to solve some NAT problems, but in this case its use was undesirable.
Related
I am creating a TCP tunnel application for RDP connections, On Server-side: Redirecting RDP connections to tunnel-server, Then sending those data to Client-side which receives the data successfully. But what happens after that? I don't know!
I know it is easier if traffic was HTTP/HTTPS because you can parse the header to address and content then send back the result. You don't even need TCP or sockets but forwarding RDP is unclear for me.
How can i forward those traffics from client-side then sending the results back to server and mstsc (windows default RDP client)? My problem is with the concept, Should i send those RDP data to client then from client machine to port 3389? And this app is considered some sort of Socks Proxy i guess.
This is the structure of what i have done at the moment:
Similar threads that aren't answer to my issue:
RDP through TCP Proxy
How to create a simple proxy in C#?
C# Proxy using Sockets, how should I do this?
P.S. The type of programming language doesn't matter for me (Currently working with c# and python but newer languages are OK too), I just want to learn how it works conceptually with a simple pseudo-code or sample, All kind of explanations or examples are appreciated.
I am trying to capture an old application that didn't honour the system's proxy setting. The only config I can change is the server IP address.
Capturing the packets with Wireshark. Without the Charles reverse proxy, I can see requests after the first three handshake requests.
With the reverse proxy, the connection stuck after the handshake requests.
I notice that when Charles received a request and connecting to somewhere but it will just stuck there:
Following is the config of the reverse proxy (Remote host removed):
Any help, solution and workarounds would be appreciated!
First of all, your app uses neither HTTP nor HTTPS. Studying screen shot of successful connection gives some details on protocol used:
the first message after handhsake is originated by server contrary to common client-server approach, where client is responsible for sending query. This fact is enough to cross out HTTP and HTTPS.
payload data isn't human-readable, so it's a binary protocol.
based on PUSH flags, protocol is much more likely to be message-based rather than stream-based
So client establishes connection, immediately gets some command from server and replies it. Then communication continues. I can't guess exact protocol. Port number might be irrelevant, but even if it's not, there are only few protocols using 4321 port by default. Anyway, it can always be custom private protocol.
I'm not familiar with Charles, but forwarding arbitrary TCP stream is probably covered by its port forwarding feature rather than reverse proxy. However, I don't really see any benefits in sending traffic through Charles in this case, capturing data on your PC should be enough to study details.
If you are looking for traffic manipulation, for arbitrary TCP stream it's not an easy task, but it must be possible. I'm not aware of suitable tools, quick googling shows lots of utils, but some of them looks applicable to text based stream only, so deeper study is required.
Reason for Failure
It may be because you are requesting a local IP address from a remote scope, which Charles proxy doesn't applies. For POS(Proof Of Statement), please refer to the below link
https://www.charlesproxy.com/documentation/faqs/localhost-traffic-doesnt-appear-in-charles/
Solution
So In order to solve the problem for the current scenario, use
http://192.168.86.22.charlesproxy.com/
Note: The url that you request will only be proxied properly by Charles not any other proxy services.
is it possible to figure out, or be notified if a peer to whom you are connected is using TCP keepalives?
Furthermore to be notified when a keepalive is sent?
Without resorting to packet-level filtering in a kernel driver?
We have a plug proxy, and a customer wishes client keepalives to be forwarded to the server. At the moment our best option I think is just to allow setting keepalives on the server-side connection, but I wanted to check if anyone knew a way to detect what the client behaviour was so that relaying of keepalives could be more closely approximated.
Thanks.
it possible to figure out, or be notified if a peer to whom you are connected is using TCP keepalives?
No. TCP keepalive doesn't use a protocol extension. It just uses the existing protocol in a specific way so as to provoke a response.
Furthermore to be notified when a keepalive is sent?
No. A TCP keepalive segment cannot be identified as such.
Without resorting to packet-level filtering in a kernel driver?
Not even if you do.
We have a plug proxy, and a customer wishes client keepalives to be forwarded to the server.
Your customer is misinformed.
At the moment our best option I think is just to allow setting keepalives on the server-side connection
Correct.
but I wanted to check if anyone knew a way to detect what the client behaviour was so that relaying of keepalives could be more closely approximated.
Not possible.
I have an openjms-0-7-7 instance running on my cloud machine. The connection to the jms topic happens over tcp. I run the client application on my personal computer at home and I am able to send messages to the topic (which then get forwarded correctly to other listeners) but I am unable to receive messages. My PC is connected to the internet through a NAT router.
I have tried to reproduce this issue using my university network and it all worked fine (there I am assigned my own external IP address - no NAT).
Am I right thinking that the problem is my router blocking the messages? How can I check this and also, how can I fix this.
Best regards,
Bart
Your router is most probably blocking incoming JMS messages as it does not know to which local client (after NAT) it belongs.
You will have to configure port forwarding in your router. Please refer to its documentation for that. To know which ports to forward, you will have to consult openjms's documentation to see how it assigns ports to clients.
In a recent series of question I have asked alot about UDP, boost::asio and c++ in general.
My latest question, which doesn't seem to have an answer here at Stackoverflow, is this:
In a client/server application, it is quite okay to require that the server open a port in any firewall, so that messages are allowed in. However, doing the same for clients is definately not a great user experience.
TCP-connections typically achieve this due to the fact that most routers support stateful packet inspection, allowing response packets through if the original request originated from the local host.
It is not quite clear to me how this would work with UDP, since UDP is stateless, and there is no such thing as "response packets" (to my knowledge). How should I account for this in my client application?
Thanks for any answers!
UDP itself is stateless, but the firewall typically is not. The convention on UDP is that if a request goes out from client:port_A to server:port_B, then the response will come back from server:port_B to client:port_A.
The firewall can take advantage of this. If it sees a UDP request go out from the client, it adds an entry to its state table that lets it recognise the response(s), to allow them in. Because UDP is stateless and has no indication of connection termination, the firewall will typically implement a timeout - if no traffic occurs between that UDP address pair for a certain amount of time, the association in the firewall's state table is removed.
So - to take advantage of this in your client application, simply ensure that your server sends responses back from the same port that it uses to receive the requests.