I'm working with freeswitch and I made the connection between my server and another one, for hearing each other I used the codec G729. The issue is the next: I call them, the call is established and I can hear the other part perfectly but they can't hear me and they can see the audio packets coming to their server but they can't hear me, any idea? Thanks!
I'd start by looking at the firewall on the remote machine. libpcap will allow you to see all packets hitting the box before the firewall rules are applied, so it can be a little deceptive. So there's a good chance that the firewall is blocking the packets.
Also, you didn't specify what the other user is connecting to their server with, and how. So if they're connecting to their server from behind NAT, then you could just be experiencing the typical one-way audio issues so common with NAT scenarios. Check out http://wiki.freeswitch.org/wiki/Nat for more info.
This issue doesn't seem to be directly related to the g.729 codec or you'd have most likely gotten a 488 SIP response.
It's possible that the person on the other end isn't able to decode the the G729 stream.
What kind of phone are they using?
I would google that phone model and try a known supported codec for it.
Then I would setup your Freeswitch to encode for that codec.
If that works then it's likely an issue with the phone.
Hope this helps.
Related
I am not quite sure I understand why this doesn't work. Is this possible? What are the pitfalls of using this if we decide it is possible?
There are actually efforts pursuing such an approach. It ultimately led to the development of coap. But plain HTTP cannot work on UDP, as all packets being sent out are essentially "fire and forget," lacking any guarantee for them to arrive their designated target. Also, order of packets can be entirely different on the receiving side. I believe there were some efforts to get HTTP running via sctp, though.
If you're seriously going down this route, you may want to look at QUIC: https://www.chromium.org/quic
I have been writing my own version of the 802.11 protocol with network stack. This is mostly a learning experience to see more in depth on how networks work.
My question is, is there a standard for replying to client devices that a certain protocol is unsupported?
I have an android device connecting to my custom wifi device and immediately sending a TON of requests at the DNS port of my UDP protocol. Since I would like to test out other protocols I would very much like a way for my wifi device to tell the android device that DNS is not available and get it to quite down a little.
Thanks in advance!
I don't see a possibility to send a reply that a service is not available.
I can't find anything about this case in the UDP specification.
One part of the DNS specification assumes that there are multiple DNS servers and defines how to handle communication with them. This explains part of the behavior in your network, but does not provide much information how to handle it.
4.2.1 Messages - format - UDP usage
The optimal UDP retransmission policy will vary with performance of the
Internet and the needs of the client, but the following are recommended:
The client should try other servers and server addresses
before repeating a query to a specific address of a server.
The retransmission interval should be based on prior
statistics if possible. Too aggressive retransmission can
easily slow responses for the community at large. Depending
on how well connected the client is to its expected servers,
the minimum retransmission interval should be 2-5 seconds.
7.2 Resolver Implementation - sending the queries
If a resolver gets a server error or other bizarre response
from a name server, it should remove it from SLIST, and may
wish to schedule an immediate transmission to the next
candidate server address.
According to this you could try to send garbage back to the client, but this is rather a hack, or an error, but how does an error look like? Such a solution assumes that you have knowledge about the service that you don't support.
I believe that the DNS - requests can be avoided by using DHCP. DHCP allows to specify DNS-servers as listed in the linked page. This is the usual way that I know for a DNS-resolver in a LAN to get initial DNS servers although I don't find anything about this in the DNS specification. You can give the Android - device a DNS-server with DHCP so that it does to need to try to query your device. Querying your device could be a fallback.
Additionally to DNS there is mDNS which uses multicasts in the network to send queries. This seems not to be the protocol you have to do with because it uses the special port 5353.
Not possible to stop DNS in the way you intend. However, only for your tests you can check the UDP messages and find out the names the device is looking for. Then you update the hosts file (google how to do it: http://www.howtogeek.com/140576/how-to-edit-the-hosts-file-on-android-and-block-web-sites/) and add those names with some localoop IP address. That might work for your test.
Other possibility is to change DNS server to some localloop IP address: http://xslab.com/2013/08/how-to-change-dns-settings-on-android/
Again, this is only to avoid having all the DNS messages through the wifi connection.
I need to implement an http server on a device that will be installed at a remote location and acessible through a cell modem. I am experience in embedded systems but I'm new to cell modems.
I was originally using this cell modem: http://www.janus-rc.com/HSPA910cf.html (based on a Telit HE910 module) for SMS alerts but now need to implement the http server functionailty.
I am not sure whether this cell modem supports the http server functionality and cannot seem to find much on the topic.
Would appreciate if anyone with experience in cell modems can shed some light on this.
The HE910 does not have any sort of built-in HTTP server, but you can still implement your own.
If you look at the documentation (Telit_HE910_UE910_AT_Commands_Reference_Guide_r5), you'll see that the HE910 has support for TCP, allowing you to use AT commands to make and receive socket connections.
It even appears (see Telit_Easy_Script_Python_2.7_r3) that the HE910 supports on-board Python with the socket module, so you should be able to implement a small HTTP server without even requiring a host to drive it.
What protocols do web cameras use for streaming audio/video feeds over the internet? HTTP? TCP? How is each frame sent inside the protocol? For example, if they use HTTP, does the web cam software encode each frame and tack it on as a query string parameter like:
http://www.some-url.com?encoded-frame=WJDJ84FU84F85594DK3DK
or, is the encoded frame set as the HTTP request's body? Similar question for TCP or any other protocol that is used.
I'm asking because I'd like to stream a web cam to a web server and have software that receives each encoded frame, decodes it, and does something with it. Thanks in advance.
Well the question in OP is open ended because it's not like there is 'one fixed set of protocols(TCP/UDP)' used in this kind of applications and also its scope is large, due to various technologies involved in this end-to-end solution of Camera capturem encoding , streaming, decoding/processing. In the case you mentioned if it is going to be likely that the webcam and the Web server are going to be on same LAN, then well you can as well use TCP/IP and then server can process it. Because on LAN latencies won't be high, so TCP would serve good. Else if on WAN, then UDP/IP can be of help.
There are plenty of tutorials online to get basics of using TCP/IP or UDP/IP sockets and its programming concepts. Then there are tutorials about streaming, packetization etc of Video data.
I don't see how HTTP can be of use here to send from webcam to a server.
For starters
http://streaminglearningcenter.com/streaming-video-consulting.html
Hope this is good to get you started.
when I type wget http://yahoo.com:80 on unix shell. Can some one explain me what exactly happens from entering the command to reaching the yahoo server. Thank you very much in advance.
RFC provide you with all the details you need and are not tied to a tool or OS.
Wget uses in your case HTTP, which bases on TCP, which in turn uses IP, then it depends on what you use, most of the time you will encounter Ethernet frames.
In order to understand what happens, I urge you to install Wireshark and have a look at the dissected frames, you will get an overview of what data belongs to which network layer. That is the most easy way to visualize and learn what happens. Beside this if you really like (irony) funny documents (/irony) have a look at the corresponding RFCs HTTP: 2616 for example, for the others have a look at the external links at the bottom of the wikipedia articles.
The program uses DNS to resolve the host name to an IP. The classic API call is gethostbyname although newer programs should use getaddrinfo to be IPv6 compatible.
Since you specify the port, the program can skip looking up the default port for http. But if you hadn't, it would try a getservbyname to look up the default port (then again, wget may just embed port 80).
The program uses the network API to connect to the remote host. This is done with socket and connect
The program writes an http request to the connection with a call to write
The program reads the http response with one or more calls to read.