I want to remote dial from my pc using a simple non SIP client program which I wrote and wchich sends commands to a proprietary SIP client that accepts remote commands via a TCP connection. The proprietary SIP client will then dial the remote party using my PC's IP and port number in SDP for RTP. Is this possible in principle? Are there any opensource clients available that use this concept? Is there any documentation (IETF RFCs, blogs etc) that is available.
Appreciate any help in this matter.
Check out pjsip, it's an open-source cross-platform SIP client for all major platforms and with API in C and an API wrapper for python, whichever you prefer. There are also examples on their site. Link your TCP parsing code to pjsip and call its functions to initiate a call, you can find how to do it on their site
If I understand correctly, here is what you want to do:
TCP SIP/SDP/RTP
PC <===> SIP client <===========> softswitch
Actually, TCP between PC and SIP client will probably be accurate for signalling but not for media as RTP media stream is often sent over UDP.
In my opinion, the first step is to make sure that your softswitch will accept sending RTP packets to an IP address which is not the same as SIP client (I think most of them refuse for security reasons). If it accepts and if you have no NAT between your SIP client and your PC, you should be able to send RTP stream directly to your PC. In this case, you have to retrieve RTP packets, eventually rearrange them, decompress their payload and feed them to your speakers.
If your softswitch does not want to send RTP packets to an IP address different from SIP IP address, then you have to forward your RTP packets from your SIP client to your PC. But if you can't modify your SIP client to do this (and it's probably the case as it's a proprietary software), you're probably stuck.
To test whether your softswitch accepts sending RTP packets to an unintended IP address, you can use sipp and specify a remote media ip address different from SIP signalling IP address.
Related
I want to use netsed to alter the incoming SIP traffic (UDP port 5060) on a PBX server which is running on a linux system (debian 10 stretch).
In the first step I simply tried to set up the phone to connect to UDP/5061 and started netsed with that command:
./netsed udp 5061 127.0.0.1 5060 s/profile-level-id=4280D/profile-level-id=42800D
The traffic was intercepted, changed and forwarded to port 5060 of the PBX software.
Unfortunately, the SIP protocol "notices" that the port used by the phone does not match the PBX (the pbx is using 5060 and the phone is using 5061 because of the port forwarding). Now the question is how to do this with netsed.
So the question is how to create a transparent proxy on the same system as the pbx.
Or is there a way to listen with netsed already on port 5060, but then pass it on to the pbx software on port 5060?
The deeper background is the Mobotix door phones for outgoing calls that do not correctly encode the profile-level-id field (it should be six base16 characters long but is five characters long). My idea was to simply change the profile-level-id as soon as the SIP-Invite enters the PBX.
Same question at StackExchange.
If I do not misinterpret your idea ; and I thing a quite interesting one ; you are trying to set up an transparent application IP proxy using netsed. From that experiment, the straightforward solution does not fit because SIP protocol "notices" that 'netsed' is altering the data-path.
Some points to be aware of :
By itself, SIP does not work via NAPT as the transferred data
contains IP addresses and port numbers.
Moreover taking aside TLS, SIP is transport protocol agnostic which
mean that a SIP session is authorized to use both UDP and TCP at the
same time.
I suggest you to have a look to SIP proxy, SBC B2BUA and STUN in order to build a correct understanding of all these issues, seem to be a hard path but valuable.
Or you can take inspiration of SIP proxy and implement minimun SIP proxying functionality into netsed. It is interesting but not so easy.
But if you abandon your initial idea of 'basic' proxy then you could use a SIP toolbox like [kamalio][1]. It is a known way of doing SIP related plumbing but obviously very far your initial goal.
Hope this help.
Can anyone tell me which Communication Protocol is used by hyperterminal connecting via Tcp/Ip ?
Protocol here means UDP, Socket/Server, other(If any).
Actually, I need to design an application (in QT, Linux as OS) to communicate to a machine (basically a printer) via Ethernet. I need to send request to the printer as well as receive response, if any, from the printer.
It can be communicated via Hyperterminal using Tcp/IP.
So I wonder which protocol should i use for the communication. As Printer simply supports ethernet therefore I have no idea, if I can use Socket/Server for communication.
Need suggestion over this. All idea/suggestion are welcome.
Thanks in Advance
You need to get your terminology right. TCP/IP and UDP are transport layers. A protocol refers to the application data that is transmitted over a transport. A socket is a programming API that allows an application to gain access to a transport so it can send/receive protocol data.
Now, to answer your question - HyperTerminal typically uses the Telnet protocol over TCP/IP. Many protocols in existence are text-based, and Telnet is largely compatible with simple ASCII text, which makes it convenient for allowing users to use Telnet UI clients, like HyperTerminal, to manually send text commands to network-connected devices. However, most devices/protocols do not use the actual Telnet protocol. But if you can communicate with a device using HyperTerminal, you can code your app to send/receive the same text commands.
We are trying to build a SIP2RTSP gateway for one of our solutions, Where in one of SIP invite is converted to RTSP SETUP request to wowza media Server and then a PlayBack is played from the mediaServer to SipClient.
But when the setup request is sent the wowza is always binding to rtsp client address even though the destination is set in transport of SETUP request header. Here we want to tell the wowza rtsp server to bind to sip UA IP and not the rtsp client ip for the flow of RTP traffic.
RFC 2326 says
destination:
The address to which a stream will be sent. The client may
specify the multicast address with the destination parameter.
To avoid becoming the unwitting perpetrator of a remote-
controlled denial-of-service attack, a server SHOULD
authenticate the client and SHOULD log such attempts before
allowing the client to direct a media stream to an address not
chosen by the server. This is particularly important if RTSP
commands are issued via UDP, but implementations cannot rely
on TCP as reliable means of client identification by itself. A
server SHOULD not allow a client to direct media streams to an
address that differs from the address commands are coming
from.
here it also tells A
server SHOULD not allow a client to direct media streams to an
address that differs from the address commands are coming
from.
What is the use of destination field and how we can direct the media streams other than the RTSP client?
The point is that client MAY request the stream to be sent at client-chosen location. Still server should be doing this carefully, and take decision whether to allow an address which is different from RTSP client address or not using security consideration such as authentication availability etc. Because sending stream blindly to any given address, esp. via UDP, is unsafe: a malicious client might easily bring server down.
All in all, destination is where to send stream to. Servers do not guarantee that streams will be sent to locations other than RTSP client's.
I'm developing a SIP mobile softphone, customer needs a complete hiding of SIP messages from softphones to SIP servers as VOIP calls are regionally prohibited, however using TLS connection was not sufficient since the message headers are easily recognized as a SIP message. What are the best common alternative?
what about openvpn, IPSec tunneling?
Transmitting SIP over TLS means the SIP headers will only be viewable if someone is able to compromise your TLS keys, i.e. it's highly unlikely unless some national security agency is on your case.
What you might be encountering is port 5061 being blocked since it's the default and therefore well known SIP TLS port. To get around that simply use a different port for your SIP TLS connection. As far as anyone viewing the traffic goes if it's not suing port 5061 they won't have any idea that SIP is being used in your TLS stream.
Of course you also need to consider the RTP traffic which is what will carry the audio part of the call once SIP has set it up. There are no standardised ports for RTP but some popular VoIP softswitches do use certain ranges by default. For example Asterisk uses UDP 10,000 to 20,000. To work around that you'd really need to use SRTP but that's going to be harder to set up since not that many SIP user agents and servers support it. It will also be easier to detect for someone watching your traffic since even without knowing the contents the profile of RTP packets would be detectable. Still it's likely to need a sophisticated entity monitoring your traffic to detect a VoIP call using SIP over TLS on a non-standard port and SRTP call amongst the general noise of internet traffic.
I am developing an application that filters and mangles packets using netfilter queue's. It's rather complicated and needs to perform well so I would like to automate some rigorous testing. To do this I need to be to be able to route some TCP connections through my system, however, I don't want to have to rely on two other machines to act as client and server. I would prefer to run a local client that sends data and a local server that checks the mangled result.
The problem is that my application needs to intercept packets at the PREROUTING stage and so packets generated by the local client can't just be routed to the loopback interface.
So I need some way to inject packets before the prerouting stage and intercept them back after postrouting. If I could somehow use stream sockets to send and receive the data that would be great!
The most straightforward way I can think of doing this is to use a tun device. The tun device allows you to inject packets from userspace that appear to arrive through the tun interface. You could either write code to create and manipulate the tun interface yourself, or you can make use of an application like OpenVPN that already does this. With OpenVPN it would be easy: no special raw sockets or anything: you just send it IP packets encapsulated in UDP and it will make them arrive through a tun interface.
I've been thinking a bit about this and using the tun devices my client and server test applications should be able to use plain linux sockets. I will explain how this can work by describing the path of a packet sent by the test client.
Prerequisites:
a) Two tun devices each providing access to a distinct subnetwork
b) routing table was set up to route traffic to the correct tun device
1) the client sends a packet to an address in the tun1 subnetwork
2) the app attached to tun1 (tun1app) will translate the dst address of the packet to an address in tun2 subnetwork and the source address to an address in the tun1 subnetwork different from the address of the tun1 interface
3) tun1app will send the modified packet back out
4) after routing tun2app will receive the packet and translate the destination address to the tun2 interface and the source address to an address in the tun2 network different from the interface address
5) tun2app will send it back out and the server will receive the packet assuming the destination port is the one the server is listening on
Packets from the server will follow the inverse path.
This seems like the core idea of a very useful tool. Does anyone know of a tool that is able to do this?
All connections from-and-to localhost itself do go over PREROUTING and POSTROUTING. Whoever tells something else is mistaken. (You can verify that with ip6tables -t raw -I OUTPUT -j TRACE, and you will see that it passes through OUTPUT-POSTROUTING-PREROUTING-INPUT when, for example, you ping6 ::1 yourself.)