Could somebody tell me what does mean 'DCS' in IP telephony communication standards?
I have looked at the internet and found that DCS is a distributed control system, but I think it's not relevant information when we talk about IP telephony communication standards.
A DCS is probably a Digital Cross Connect System in the context you have seen it, although it also seems to be a popular set of letters to include in product names, so check that it is not simply this you are seeing.
A digital cross connect is a 'box' or device that allows you switch between digital circuits - e.g. connect an incoming digital 'trunk' to an outgoing digital 'trunk' or phone 'line'.
You are correct that 'pure' IP telephony does not generally have to use cross connects as it is packet switched rather than circuit switched, but in the real world most IP telephony systems have to interface with or connect to older digital circuit networks and equipment.
For this reason you may see devices which act as a gateway between IP telephony networks and circuit switched digital networks - these boxes are often called Media Gateways.
See more about DSC at: http://en.wikipedia.org/wiki/Digital_cross_connect_system
Related
I am still trying to understand DDS and its concepts.
I have a configuration where 2 laptops run dds based application. My environment does not permit multicast so I decided to go for peer to peer connection(unicast). To bring both the laptops in the same network, I connected them using ethernet cable (Not sure if it was necessary or not).
Now I did not change anything in the QoS i.e. i did not do any settings for unicasting. But now my applications are communicating with each other.
Question :
How are the participants being discovered ? Multicasting ? as I did not do any settings for unicasting.
Was it necessary to bring them under one network i.e. connect with ethernet cable if I wanted to use unicasting ?
EDIT :
Configuration is as follows :
First laptop : Windows OS : Native DDS based application : Publisher : Multicast not allowed.
Second Laptop : Linux : ROS2 based subscriber : Multicast no problem
Out of the box, DDS is required to support Multicast and Unicast Discovery. Anonymous connections are handled through multicast. If you know the IP address of the recipient, you can manually configure those addresses into the unicast discovery list (each vendor will have their own way to name/process this list).
"Multicast is not permitted on our network", in most cases, means that your IT department has turned off multicast packet forwarding at the switch (or the switches) that define the fabric that is your network.
The as-shipped, standard-compliant DDS configuration, however, has no knowledge of this local policy (how could it?). If you haven't changed the configuration in line with your local policies, the DDS Participants are still going to try to connect via Multicast, because you haven't turned it off.
If the DDS-using machines are connected to the same hub, or to an unmanaged switch (defined here as one that your IT department doesn't care about, or is misconfigured), and the network topology does not cross a managed switch, and they are using the default configuration, and they find each other, then they are using Multicast anonymous discovery.
Figure out how to configure your DDS implementation, to add the unicast ip addresses of the machines that need to communicate. Because discovery is usually only needed in one direction (if A discovers B, then it is true that B has discovered A, assuming neither A nor B are configured to ignore the other[1]).
Once you have configured for unicast discovery, you can configure for no-multicast. If the machines are on IP hopping networks (WiFi, etc) it will be difficult unless the DDS implementation understands multipathing. Talk to the vendor to see if this is the case.
[1] DDS is nothing if not overly configurable.
How are the participants being discovered ? Multicasting ? as I did not do any settings for unicasting.
It is not possible for me to answer this question with complete certainty since you are using DDS as part of the ROS2 framework and I am not familiar with the exact details of how the two are set up to interact together. Having said that, from your description it does seem that the participants are indeed using multicast to discover each other.
The best way to get a conclusive answer is by sniffing the network -- assuming that you have the required privileges to do so. For example you can use Wireshark , which comes with an RTPS dissector that allows you to filter on RTPS messages. (RTPS is the name of the standardized DDS wire protocol.) Check out the destination address and see if you detect any addresses in the multicast range. You can do this while firing up a single DDS-based application. It will start announcing itself over the network immediately.
Was it necessary to bring them under one network i.e. connect with ethernet cable if I wanted to use unicasting ?
If you want to use unicasting, you will need to know IP addresses or host names of all peer nodes. As long as those peer nodes can reach each other over UDP, you are good to go. Often, but not always, ping will let you know whether this is the case. Firewalls are a typical cause of problems.
However, be aware that different types of network have their own specific properties that you might have to adjust your configuration to. Over WiFi for example, the likelihood of packets being dropped (especially with bursts of data) is much larger than when connecting nodes directly with a wire. DDS allows for tuning its protocol to deal with that.
We are planning to use Ethernet bus topology (wiki). The reason using this very old topology is hardware limitations and software requirements. Collisions should be OK, as bandwitdh requirement is very low.
My problem is, how can we test this topology with modern Ethernet controllers and software like Ubuntu etc. I could not find a good implementation example.
I have tried connecting three Intel Ethernet controllers (with Static IPs) together and only two of them had link at a time (they worked in point-to-point connection as usual)
"Modern" hardware is rather limited when trying to build a bus topology - it's much easier to build a more usual star/tree network. However, with the right key components you can even connect both topologies.
From the software point of view, the network just "works", i.e. as long as the network is configured correctly the software applications can (and should) be oblivious to the network layout.
With an assumed Ethernet network, the logical structure of each segment is a bus anyway: each device can just talk to any other device, regardless of where and how they are connected.
I am currently working on some design concepts that would see me have the requirements for the following type of system.
In short I am looking at ways to Tunnel a connection through NAT similar to VPN but without the complexity.
I have a small embedded linux device that sits behind a home LAN that I would like to be able to interface with through an API that I have created.
Currently the setup I have is as follows:
Device A (Embedded Linux) - Public IP
Device B (Amazon Server)
I am using a REST/Json api to control Device A from Device B.
I am looking for a protocol or solution that would allow me to send two way communication from Device A and B possibly by adding a third proxy server to handle this "Tunnelled" connection.
Notes:
Would preferably like to avoid complex VPN's and the need for the NAT device to support VPN Passthough.
Traffic between Device A and B is small and not highly sensitive but some security like SSL would be nice.
This is a multinode system, Hence, There are many Device A's.
Any advice as to where I should be looking would be greatly appreciated.
Regards
pjf
Recently i had a case where i was trying to establish a p2p connection using Microsoft PNRP technology between two applications. One application was on Lan and another was on same Lan (diff computer but same Service provider) but was behind a WiFi router. Since, I registered the two peers in all clouds(Global & local links) on respective system but when i tried to resolve the another i could not find the respective peers. As far as i know those peers must be discoverable since i also registered them in global cloud (Internet). How can i achieve the aforesaid scenario ?
Using PNRP in this way depends on a couple of technologies, the most important of which is Teredo tunnelling. You've probably run into a restriction of Teredo tunnelling and how it works behind firewalls.
To summarise it, Teredo routes IPv6 traffic over UDP packets sent to a specific port with IPv4. Because of this only certain kinds of NAT are supported for direct connections. You'll probably find that each of your systems can resolve themselves and other services, but not each other within the firewall if they're on different networks.
The easiest way for you to resolve this will be to either make the computers connect to completely different networks, or have them on the same network (as PNRP also supports link-local discovery).
More information can be found on Wikipedia.
If i am publishing a NSNetService in (Bonjour based NetWork) Iphone Application,which net Work will use in my application
If you use the high-level NSNetService methods, (on both OS X and iOS) the NSNetService will be published through any network interface that supports multicast packet transport. Since bluetooth supports this, you should be able to broadcast mDNS data over a PAN, although service advertising and discovery may be slower than on a normal IP network. Have a read through this for more information.