Interesting issue I have never run into before with Asterisk.
Using Asterisk 1.8.x (please don't tell me to upgrade, it's not possible at this time).
When someone dial direct into the system to any of the numbers, we Answer, then push them to a queue and either play MOH on Ring sound.
This has always worked fine and still does. Most people forward calls to our numbers from their business line/phone system.
For this one customer and only one customer, there is complete silence for the caller once their phone system initiates the forward to our number. Our Asterisk box answers the call, we have even tried playing sounds using Playback etc but nothing, complete silence until one of the agents answers from the queue.
Really bizarre. canreinvite=no is set so, there shouldn't be any issues with Asterisk getting optimized out.
Any ideas a really appreciated. I know it's on their end but, it would be great to find a way to make Asterisk, make the customer's phone system behave correctly LOL.
You would have to take a wireshark trace at Asterisk box and check INVITE offer and 200OK response from asterisk. Then make sure that media RTP are sent to IP address in connection information line c= and port specified on m= media line. You also should check if rtp payload (codec) match the request and answer. Asterisk probably will respond with one codec from INVITE offer. When media are sent but caller does not hear anything before an agent answer the issue is probably on caller side. Hope helped a bit to tracę the issue.
I had the same problem once, but the other way around. I was the client dialing into someone else's system using my asterisk system. I tried everything in my hand, including pestering my (E1) telephony provider to no avail.
To this day I still don't know the reason for this behaviour, but I've managed to get around by Answering the call originated from my system BEFORE dialing the PSTN, thou this is far from ideal.
Something like this:
Answer()
...
Dial(YADAYADAYADA)
I know this isn't exactly the answer to your problem, but I hope it helps in any way.
Very likly you have issues with codecs. I.e customer use some codec you have no translation module, but agent's customer have
Related
I do realise this question sounds off-topic for SO - it's probably more on-topic for Travel.SE but it is also really a debugging question and requires a bit of a hacker mindset to debug, so I figured SO is the place to go.
Here's the problem: When I make an international call from my phone on H2OWireless (a reseller using the AT&T GSM network), the receiving end of my call gets a wrong country code transmitted as caller ID, causing a number of problems.
I have a US phone number with area code 803. If I make a call to Germany, the receiver of the call sees my caller ID as 00803xxxx, which does not make sense. My caller ID should be shown as +1803xxx or 001803xxx, but for some reason, the leading "1" gets lost.
That causes the following problem: I can call regular dumb landline phones in Germany, but when I try to call my bank, my call bounces at their switchboard. I guess they are doing some kind of a reverse-lookup and find that +8 or +83 is not a valid country code, and refuse to accept that call.
I have temporarily solved the problem by having a friend setup a call forwarding for me, so he forwards my call to my bank when I call him.
But I would really like to understand what is going wrong here, and whether AT&T or Deutsche Telekom or any other provider is to blame for this problem.
I would appreciate any insight from phone network experts as to how to debug the problem, so that I can see who is causing this before I write a mail to either AT&T support or the german provider.
The problem is most likely the reseller not mapping the calling number correctly - I would write the letter to them. It will be much easier for them to debug it than for you, especially if they are actually obliged to do it correctly by law/licence (I am not sure what the rules are in the US). If it is a problem with someone else they will normally be delighted to let you know (!) and you can then chase the guilty party instead.
The reason this most commonly happens is because the reseller generally jumps off the regular network to their own IP network and they have to translate the call setup info to match the protocol they are using on their own network (probably SIP based unless it is quite old). It is not uncommon for CLI data to get mixed up this way.
I'm experimenting with my Arduino Mega. I also have an Arduino Ethernet Shield.
I need to send emails using them, without the help of a computer (or any other device; like a smartphone, etc.). Though I could find several articles, I couldn't find any acceptable solution...
How can I do it? As I'm not asking this to be used for any special application, you can
make any assumption about missing details.
From the discussion above in comments it sounds like you either need code from someone who has just done it for you or you need to take the time to learn about the components and find or make the components.
They wouldn't make an Ethernet shield for this platform if it was only useful for non-standard packets. So someone somewhere has created some level of an IP stack.
Backing up though, in order to send mail you need to learn the Simple Mail Transfer Protocol (SMTP). Almost all Internet protocol definitions are defined using something called RFCs (Request for Comments). So if you google SMTP RFC you will find RFC 2821.
IETF is Internet engineering task force. There will be many copies of these documents on many websites. And due to the age of the Internet and these protocols in many cases you will find that one RFC has been created to replace a prior one. Version numbers are not used, but it is kind of like HTML 1.0 then HTML 2.0 and so on. I recommend even though the RFC says that it completely replaces RFC xyz, go find RFC xyz and read it. I go back as far as I can find learn that one then work my way forward.
Many/most protocols that ride on top of TCP (TCP is yet another protocol defined in an RFC, more on that later) are ASCII based, makes it very easy to, for example, Telnet to learn/experiment with the protocol, you can probably use Telnet to learn SMTP.
Most protocols are some sort of a half duplex thing, make a connection and often the server sends you a string, you see that string and then you send some sort of hello string, the server responds with some sort of OKAY or fail status. For SMTP, you then do some sort of I am mailing from this email address, server says OKAY, you say I want to mail this person or this list of people, for each email address you get an okay or fail. Eventually, you tell the server you are ready to send the body of the message, you do that, end the message with the defined termination. Then either the server says okay or fail or maybe there is some more handshaking.
The protocols in general though have this back and forth. Usually you are sending strings with commands and usually the server side sends back a short okay or error. Sometimes, if they want, they send back more detail on the error, but always start with the few bytes that indicate okay or error. The protocols generally have a flow, you must do this first then this then that.
You should learn sockets programming, sometimes called Berkeley sockets. You can write programs that are mostly portable across unixes but also across to Windows using Windows sockets if that is your platform of choice. You need to learn the protocol first, and it is better on your desktop/laptop and not embedded, you can get it done faster there. You do NOT have to learn to fork or thread to use sockets. The examples may show that as it is easy to show it that way, but you can write complete applications using polling only, it is half duplex send something, wait, send something, wait. For these simple learning programs, a little time up front to learn sockets, from there, it is all learning the protocols.
Now that was the very easy part, the hard part is the TCP/IP stack. I do not recommend attempting that without gaining a lot more experience taking baby steps on your way there. For example, learn to respond to ARP first (yet another RFC protocol, address resolution protocol) then ping (ICMP echo, one subset of the ICMP protocols) then IP basics (sniffing packets) then receive and generate UDP packets. TCP is a whole other level above that, more handshaking. It is not fixed packet size, it is streaming, do not have your code operate on packets, it is a stream of bytes, like working with a serial port.
Doing your own TCP stack is very much a non-trivial thing, I don't recommend it, you need to find someone that has done a TCP/IP stack for this platform for the Ethernet shield and just use it, whatever RTOS or environment they use, use it. Then take your desktop/laptop based experience with the protocol and apply that.
From the discussion above, if you don't want to learn the protocols, etc., I think you need to google around looking at Arduino Ethernet shield examples and see if anyone has done something that sends emails.
I'm playing a game and i'm trying to send some custom requests to the server in order to perform some tasks easier .. While i will gain little to none from this, i have become very interested in the educational part of it.
Since the game runs partially on client via a .jar and/or a .cab file i think it is run by JVM - correct me if im wrong
I have captured some traffic send by the game via wireshark. The protocol is TCP and it looks like this:
!, 1338,102,264,0.0 ,0.0,32433553,0, 102,264,
Nevermind all the numbers - thats for me to figure out.
But when i create and send a similar packet via a couple of different programs it always fails. This is of course because i am sending the wrong sequence number along with the TCP-packet.
So in order to not mess up the sequence-number i figure i will have to inject the process running the game and then somehow make it send my custom packets.
How do i go about that ?
You can't mess with the TCP sequence number in pure Java. Java doesn't even do that itself, the TCP stack does all that.
It is most unlikely that this is your real problem.
im looking for a way to detect, and capture data being sent TO and FROM a specific program, ive attempted to use something like wireshark but it all seems to be a bunch of nonsense to me, so i was wondering if anybody could help me get the data, translate it into text, to allow for editing, and then to resend the new edited information on its way.
Look for Capture TCP stream feature/menu item in Wireshark.
Edit: It's actually Follow TCP Stream.
Wireshark is definitely the way to go. It'll capture the data going to a specific port (which you can probably correlate to a the program fairly easily). I hope this isn't happening over SSL though (wireshark isn't going to help you much if it is).
But if you have to reverse engineer the server's communication protocol, capturing the network packets is the least of your problems. Reverse engineering is difficult and can be fairly error prone as it's often based on guess work. My suggestion is to do this as a last resort: if the server is intended to communicate with the outside world, there's probably some protocol documentation floating around somewhere that will be much more reliable than a wireshark trace.
This is more a thought experiment than anything.
I'm wondering what it would take to detect everything I legally can about the laptops in a hotspot. My first thought was to grab every MAC address I can and extract the maker from the first 24bit.
The question is would this be illegal and what else could I legally scavenge, preferably passively?
P.S. This constitutes a pattern-recognition problem so it IS programming... I think.
nmap can do a reasonable job of guessing the operating system by the way the target system responds to various probes
For the brain dead answer: Quit typing and look around for a few minutes :-D
I guess the obvious one would be to sniff the user-agent out of their HTTP requests.
IIRC there are ways to detect what TCP/IP stack is being used by sniffing choices in port usage and sequence numbers.
Why does it matter, 90% of them will be apples ;-)
The people wearing black turtle necks will be using Macs, the rest will be using PC's and Windows (except for that one guy with long pony tail who is using Linux).
Packet sniffing is illegal without the network owners consent. At least that's the generally followed precedent. There has been very few tests of this in court. But your idea of how to do it, using the mac addresses, would work well. Wireshark is a good packet sniffer if you're looking.
GFI Languard gives a lot of info like this. Check it out.