In a cellular environment, the ip address assigned for a phone changes dynamically.
So i wonder how WebRTC deals with this issue.
Does WebRTC has some feature called 'Path Migration' like QUIC ?
Is ICE Restart what i am finding?
There is an RFC8016 TURN about mobility to reuse TURN session in case of IP change, but it is AFAIK not implemented in the actual WebRTC stack.
AFAIK WebRTC does not handle yet this case.
You could detect the error on client side and restart ICE agent.
Related
I am puzzled...
My project is a PC connected to multiple micro-controller boards in an isolated network. So far the protocol has been UDP which is easy to deal with, has no particular client/server but has its obvious shortcomings of lost messages when things get busy.
The micro-controllers have fixed IP-addresses (set by dip switches), the PC SW has a list of them, sends at present UDP messages to each of them and they reply to the address they came from (i.e. the PC) with status and/or data.
My question is now that I switch to TCP instead of UDP, should the PC be the listening server with many clients (could be anything from 1 - 50), or should the micro controllers be listening servers the PC can connect to as client? Note: controllers have fixed/known addresses - the PC does not.
An additional concern is re-connection. The micro-controllers are external and may lose connection, reset or otherwise need to connect again.
Thanks....
should the PC be the listening server with many clients (could be anything from 1 - 50), or should the micro controllers be listening servers the PC can connect to as client?
That is a basic design question that we cannot answer for you. Likely, it's more practical for arbitrary devices to connect to a central server but that's not a given.
controllers have fixed/known addresses - the PC does not.
That might turn the previous question around.
The micro-controllers are external and may lose connection, reset or otherwise need to connect again.
That's something you need to put into your design - have TCP connections time out and reconnect. Usually, a finite-state machine is useful here. You should also consider whether you use a one-shot connect-transmit-disconnect similar to UDP (easier to implement) or a longer TCP session with multiple data transmissions (more efficient).
I have implemented basic WEBRTC peer connection between two clients and uses RTCPeerConnection and getUserMedia APIs for it. I am fetching Audio tracks only from the stream.
Even though my signalling works, ice agents are shared, streams are shared as well.
The audio comes out distorted completely.
However, if I utilize a VPN on one device the other device can hear the audio coming from the device with VPN very clearly with no hiccups.
NOTE:
I tried this with only stun and with a combination of stun and turn servers(viagenie).
Can someone tell me how do i debug the issue, what to look for?
Is my ISP involved in messing around with the media stream? (I live in the UAE.)
Thanks in advance!
i think the problem is UAE ISP block the STUN/TURN PORT (3478,5766 ...)
you can try to use 443/80 port?
I want use Alljoyn to communicate between devices in smart factory.
However,it seems there is no such use cases not yet.
So,i want to know if Alljoyn can't be used in factory for some technical reasons,
for instance,stability or performance.
In my case, I need device can communicate directly.
So,publish-subscribe-based protocol,like MQTT,wouldn't work for me.
I don't get the specific problem of your case. But I'm going to answer anyway.
AllJoyn runs on the proximal network (local network) by using Wi-Fi, Ethernet or Power Line (PLC). And AllJoyn does not require a cloud to function, cloud network connection is optional. It works in your case as long as the local network functions properly.
Transport name Value Description
TRANSPORT_NONE 0x0000 No transport.
TRANSPORT_LOCAL 0x0001 The local transport.
TRANSPORT_TCP 0x0004 Transport using TCP as the underlying mechanism.
TRANSPORT_UDP 0x0100 Transport using UDP as the underlying mechanism.
TRANSPORT_EXPERIMENTAL 0x8000 Select a release-specific experimental transport.
TRANSPORT_IP 0x0104 Allow the system to decide between TCP or UDP.
TRANSPORT_ANY 0x0105 Allow the system to choose any appropriate transport.
AllJoyn supports both TCP/IP and UDP/IP transport mechanisms. While developing your app, you can decide to use which transport mechanism you want.
AllJoyn documentation states that;
If an AllJoyn application desires to only use TCP as the underlying
layer 4 mechanism, it can do so by specifying TRANSPORT_TCP in
advertisement, discovery and Session join and bind options.
As TCP guarantees all sent network packages will reach their destination in the correct order. In your case you can choose TCP communication as a more reliable option.
I am using csipsimple as sip client and asterisk server to set up call. Calls are made between 2 sip clients but voice is not getting transferred.
Calls are made between 2 sip clients using AMI.
I can give my asterisk cli log.
Can anybody please give me some idea to solve this issue?
Thanks
More info would be useful. First, make sure both clients are registered, and can use at least one common codec. In most cases, these aren't the problem. It's usually a NAT/Firewall issue. Are the two clients on the same subnet? Is there any firewall rules blocking the communication?
SIP signaling usually goes on udp:5060. But that seems working. Media is tricky. In each call, the ports for RTP audio changes, in the range specified in rtp.conf. This RTP traffic goes over UDP as well. By default it't 10000-20000.
If there is only routing done between the two endpoints, it should still be fine. NAT (Network Address Translation) is your main concern. Take a look at iptables, sip_nat_conntrack. To debug, use asterisk's sip set debug on command and look for the SIP headers and verify the correct IP addresses.
How can I connect a system to a network and sniff for virus/spyware related traffic? I'd like to plug in a network cable, fire up an appropriate tool sand have it scan the data for any signs of problems. I don't expect this to find everything, and this is not to prevent initial infection but to help determine if there is anything trying to actively infect other system/causing network problems.
Running a regular network sniffer and manually looking through the results is no good unless the traffic is really obvious,but I havn't been able to find any tool to scan a network data stream automatically.
I highly recommend running Snort on a machine somewhere near the core of your network, and span (mirror) one (or more) ports from somewhere along your core network path to the machine in question.
Snort has the ability to scan network traffic it sees, and automatically notify you via various methods if it sees something suspicious. This could even be taken further, if desired, to automatically disconnect devices, et cetera, if it finds something.
Use snort: An open source network intrusion prevention and detection system.
Wireshark, formerly ethereal is a great tool, but will not notify you or scan for viruses. Wireshark is a free packet sniffer and protocol analyzer.
Use the netstat -b command to see which processes have which ports open.
Use CPorts to see a list of ports and the associated programs, and have the ability to close those ports.
Download a free anti-virus program such as free AVG.
Setup your firewall more tightly.
Setup a gateway computer to let all network traffic go through. Take the above recommendataions to the gateway computer instead. You will be checking your whole network instead of just your one computer.
You can make Snort scan traffic for viruses. I think this will be the best solution for you.
For watching local network traffic your best bet (with a decent switch) is to set your switch to route all packets out a specific interface (as well as whatever interface it would normally send). This lets you monitor the entire network by dumping traffic down a specific port.
On a 100 megabit network, however, you'll want a gigabit port on your switch to plug it into, or to filter on protocol (e.g. trim out HTTP, FTP, printing, traffic from the fileserver, etc.), or your switch's buffers are going to fill up pretty much instantly and it'll start dropping whatever packets it needs to (and your network performance will die).
The problem with that approach is that most networks today are on switches, not hubs. So, if you plug a machine with a packet sniffer into the switch, it will only be able to see traffic to and from the sniffing machine; and network broadcasts.
As a followup to Ferruccio's comment you will need to find some method of getting around your switches.
A number of network switches have the option of setting up port mirrors, so that all traffic (regardless of the destination) will be copied, or "mirrored", to a nominated port. If you could configure your switch to do this then you would be able to attach your network sniffer here.
Network Magic, if you don't mind something that's not open source.
You can use an IDS, hardware or software
http://en.wikipedia.org/wiki/Intrusion-detection_system