I am working with an IP camera based on onvif standards. The scenario is the following one:
The RTP port and HTTP port are 22554 and 22280 respectively. I have no problem with this, I reroute the traffic from A to B in those ports to reach the camera. In fact, the RTP session is correctly established.
The problem comes in the SETUP message. Here A (which starts the session), establishes a new port (client port) for the UDP connection for video interchange. The same way, the camera also sets a new port (server port). As the server ports are not redirected in B, I am not able to receive anything.
I read that there is a possibility to used interleaved mode in order to use the same port used for RTSP messages (22554 in this case) for the video packets. But I do not know how to do this. For example, VLC tries the first option (new client-server ports) and as it does not work it successfuly setups another rtsp session with interleave mode.
I started working with this code (http://bit.ly/1Xvwqx9), which is based on Onvif libraries. But I cannot find anything regarding this aspect of interleaving.
Anyone can give me a hint?
Thanks and kind regards.
Finally I found the solution. It is important to set these aspects:
protocol = TransportProtocol.rtsp
MediaStreamInfo.Transport transp = MediaStreamInfo.Transport.Tcp;
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.
In an SDP message, the "Origin" ('o') attribute is defined as:
o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
Where <unicast-address> has the following definition:
is the address of the machine from which the session was created.
However, I'm unclear on whether this should be the IP of the client, or the RTP server. For example, if the client is running VLC on IP 1.1.1.1, and the RTP server is serving media from 2.2.2.2, should the <unicast-address> be set to 1.1.1.1, or 2.2.2.2?
I take it to mean the machine which creates the session and actually generates the SDP message, i.e. not the RTP server (the address of the RTP endpoints are defined elsewhere in the message). That's how I've always implemented it in the past.
The unicast address is of the server thats creating the RTP session. Usually it carries the IP address but for reasons of obfuscation the IP can be switched to FQDN or even something relatively obscure that for purposes of debugging can only be understood by the application developers.
It doesn't have any significance w.r.t to SDP / RTP processing.
Such as Skype/Team viewer/Logmein etc application, which send audio/video behind NAT (behind firewall). But when i make a small tiny application which send text to another NAT location it failed to do the same.
Example:
Sender:
-> Public ip: 91.1.2.3 My lan ip is: 192.168.1.2 with port 14446 udp
-------> Data format: RTP packets
Receiver:
<------- Data received: 0 packets
-> Public ip: 92.1.2.3 Friend lan ip is: 10.0.0.2 with port 14446 udp
* same in both way
How others does this? What is the way of doing peer 2 peer application development to overcome NAT issues? Always we have public ip's and mostly it has NAT issues.
But how does then Skype works in such cases too? Do we have a audio/video port range for UDP or always UDP is open from anything? But mine does not work above range ports for UDP i also tried. What is the secret? that is making me curious!!.
Note:
My goal is audio packets handling where i believe too much filtering or firewall cause latency and delay and other issues gets involved relatively too. So i would like to know very clearly for my application that some of the ports (which port ranges?) can be used for such purposes, where it really not blocking development stress.
There are a number of types of NATs, which vary in what traffic they'll allow in.
See the Wikipedia article on NATs
For most NATs, STUN will let you open ports AND find out what port you opened (may be different than the port you sent from). In SIP and RTSP you'd typically provide the external IP and port determined by STUN to the other end.
A fully-symmetric NAT means that STUN won't let you use a 3rd-party server to prop ports via STUN, so you'll have to use UPnP (if enabled) or map ports in the router (or set up triggers), or you'll have to play evil games to make both sides think they initiated the connection. (Not easy and not guaranteed.)
See the ICE & TURN specs (RFCs) from the IETF for detailed mechanisms to traverse NATs - though note that in some cases you must use an external proxy to forward packets.
One common solution is that the client program connects outward to the server and thus establishes a connection. Most firewalls allow outward connections - the assumption being that you are trusted and can always connect to the outside. When the server then wishes to send a message to you, it responds on the open connection.
I believe the port that you use is what is usually used to determine if it should be allowed or not. Certain ports are always let through. I'm not sure of the exact ports, but that will be different for all NATs and firewalls.
How can an application be designed such that two peers can communicate directly with each other (assuming both know each other's IPs), but without outgoing connections? That's, no ports will be opened. Bitorrent for example does it, but multiplayer games (as far as I know) require port forwarding.
I'm not sure what you mean by No Outgoing Connections, I'm going to assume like everyone else you meant no Incoming Connections (they are behind a NAT/FW/etc).
The most common one mentioned so far is UPNP, which in this context is a protocol that allows you as a computer to talk to the Gateway and say forward me this port because I want someone on the outside to be able to talk to me. UPNP is also designed for other things, but this is the common thing for home networking (Actually it's one of many definitions).
There are also more common and slightly more reliable ways if you don't own the network. The most common is called STUN but if I recall correctly there are a few variants. Basically you use a third party server that allows incoming connections to try and coordinate a communication channel. Basically, what you do is send a UDP packet to you're peer, which will open up you're NAT for a response, but gets dropped on you're peer's NAT (since no forwarding rule exists yet). Through the connection to the intermediary, they are then told to do the same, which now opens up their NAT, and matches the existing rule in you're NAT. Now the communications can proceed. Their is a variant of this which will allow a TCP/IP connection as well by sending SYN and SYN-ACK messages with some coordination.
The Wikipedia articles I've linked to has links to the relevant rfc's for these protocols on precisely how they work. Essentially it comes down to, there isn't an easy answer, as this is a very network centric problem.
You need a "meeting point" in the network somewhere: the participants "meet" at a "gateway" of some sort and the said "gateway function" takes care of the forwarding.
At least that's one way of doing it: I won't try to comment on the details of Bittorrent... I am sure you can google for links.
UPNP dealt with this mostly in the recent years, but the need to open ports is because the application has been coded to listen on a specific port for a response.
Ports beneath 1024 are called "registered" because they've been assigned a port number because a company paid for it. This doesn't mean you couldn't use port 53 for a webserver or SSH, just that most will assume when they see it that they are dealing with DNS. Ports above 1024 are unregistered, so there's no association - your web browser, be it Internet Explorer/Firefox/etc, is using an unregistered port to send the request to the StackOverflow webserver(s) on port 80. You can use:
netstat -a
..on windows hosts to see what network connections are currently established, including the port involved.
UPNP can be used to negotiate with the router to open and forward a port to your application. Even bit-torrent needs at least one of the peers to have an open port to enable p2p connections. There is no need for both peers to have an open port however, since they both communicate with the same server (tracker) that lets them negotiate and determine who has an open port.
An alternative is an echo-server / relay-server somewhere on the internet that both peers trust, and have that relay all the traffic.
The "problem" with this solution is that the echo-server needs to have lots of bandwidth to accomodate all connected peers since it relays all the traffic rather than establish p2p connections.
Check out EchoWare: http://www.echogent.com/tech.htm
I am designing a p2p application which works on port 30000. My router is not UPnP so I required to forward a port to router. But Skype a another p2p application works without port forwarding on my pc. When I analyzed it with wireshark I found its using UDP port 48980, 58544. I am using c++.
There is a library in python here which does it for Nat PnP routers. Is it possible to programmatically forward port to router irrespective of type of router and operating system. What should be the approach to do it in c++ or any other language.
Skype works in a very interesting way. From what I've read (and this is a while ago) it works as follows:
Skype server maintains a list of all
users and IPs.
Skype user A wants to
speak to user B
Skype user A sends a
network packet to user B's IP address
and waits for a response. (user B never gets this packet).
Skype user A notifies server of IP/port
combination on which it is waiting
for a response
Server notifies user B
to send a response to user A on the
specified port
A connection is made.
This is probably over simplified but last I checked, this is how it works. (Someone correct me if I'm wrong).
Edit: fixed bullet issue
UDP hole punching is (one) of ways how to traverse through the NAT.
You have to use an intermediary server, and initiate communication from the client side. As Yossarian mentioned, from that point one possibility is UDP hole punching. Depending on the type of application (and whether it's truly P2P or not) you might keep the go-between server in place the entire time.
Skype uses another peers as intermediate point when direct connection is not possible.
i.e. Peer A wants to connect to peer B, but peer B has all ports closed, then communication is initiated through peer C which has open ports.