I'm using Asterisk 11, a Cisco SPA303 Phone, and Twilio.
I can make outgoing phone calls without any issue and the call quality is top notch. On an incoming call however, my extension (and phone) ring, however when I answer the phone, there is no audio on either end and 30 seconds later, both calls end. Using Twilio's PCAP log, it shows that my asterisk server sends a BYE when answered. Asterisk however does not log a single thing on incoming calls. (All SIP traffic is logged on outgoing calls). Does anyone have any idea what's going on?
Update:
Turns out that I had my incoming extensions in the wrong context, once that was updated, incoming and outgoing calls worked without a hitch. I marked #arheops as the answer because the logging of unanswered calls lead to the diagnosing of the problem.
Very likly(but you not informed) your asterisk installation is after NAT.
IF so, you have configure asterisk as described in http://www.voip-info.org/wiki/index.php?page_id=410
Also may need change ports on router/disable SIP ALG on router etc.
Logging(you mean cdr,right?) is controled by /etc/asterisk/cdr.conf
Most likly you have ananswered=no in that file.
Related
I have a SIP Server running OpenSIPs 1.11.3
configured with built-in STUN module (full mode with 2 IPs)
configured with MediaProxy 2.6.1 to relay RTP (using engage_media_proxy in routing script)
Using IMSDroid from doubango as the SIP client.
Calls between wifi-wifi is good, I do not need to turn on any STUN, ICE, TURN option in the client.
However, calls between 3g-wifi or 3g-3g isn't that good. 3G can make outgoing call but it cannot receive call. Which means 3g-3g call can NEVER happen. All I see in the OpenSIPs logs are repeated retransmissions of INVITE because it cannot reach the 3G side.
I read that TURN server can solve this kind of problem, so I enabled TURN in IMSDroid sip client, but still 3G side cannot receive any call.
The TURN server I am using:
url: 'turn:numb.viagenie.ca'
credential: 'muazkh'
username: 'webrtc#live.com'
Is there any solution / module I can use to solve this problem?
EDIT:
If I use TCP protocol, I am able to receive call! Although the call terminate due to transport error after 30 seconds, but at least the call went through. Any idea what happen here?? Mobile carrier blocking incoming call? But definitely not port blocking because I am able to register whether I use port 80 or 5060.
EDIT 2:
I tried using free SIP accounts to make calls (sip2sip.info and sip.antisip.com), and I have the same problem too! As I know, sip2sip.info is using OpenSIPS too but AntiSip.com is using something like AmSIP. So the problem is with my mobile carrier?
Thank you!
If your UA can't receive calls, it means it is not reachable for signaling. In order for your UA to be reachable, it needs to register and keep the NAT mappings alive. To keep a NAT mapping alive, your UA must send keepalive to the server periodically. Another option is that the server sends keepalives to the UA but some NATs don't refresh mappings for incoming traffic.
When you solve this first issue, comes the media part where technologies like STUN, TURN and ICE will help.
My PC has two gigabit ethernet connections (NICs) - one on the motherboard, and one on a plugin card. I've never used multiple NICs before, and I'm simply not clear on how the OS resolves which NIC to use, and at what stage it occurs. Chance are "you don't have to know" because it happens automatically... but I'd still like to know - does it happen when you call the bind() function, for example, or later during a send or receive? Is it precisely the same process prior to both send and receive? Is it the same for TCP, UDP or any other protocol? Is it different between Windows and UNIX/Linux or Mac systems?
I'm motivated to ask because I have some Winsock2 code that "was working fine", but which stopped working when I reversed the order of the send and receive on a single socket. I discovered that it only received when there was at least one packet sent first.
I'm 99% sure there will be a bug somewhere, but I'd like to be 100% sure in the unlikely case that this is a "feature", or a bug beyond my code... because the symptoms are consistent with the possibility that the receive functionality is working fine, but somehow waiting to receive on the wrong NIC.
It consults the IP routing tables to find the cheapest route, whuch determines the outbound NIC. This happens when you connect(). In UDP if you don't connect, as you usually don't, it happens on send().
I'm trying to generate ARP (Address Resolution Protocol) request packets on the iPhone and listen for the associated responses that come back.
Google searches have led me into a dead-end. In order to send logical-layer packets, I'd need something along the lines of a raw socket, but need super-user permissions to create them. I'm trying to avoid jailbreaking my phone.
There's lots of c code out there that can do this, but I can't find anything that can translate to iOS due to the permissions.
I was ready to throw in the towel when I decided to Wireshark a couple network discovery apps I have. Namely "Fing" and "Pinggy" (hats off to Fing and Pinggy btw... awesome apps!)
https://itunes.apple.com/us/app/pinggy/id562201096?mt=8
https://itunes.apple.com/us/app/fing-network-scanner/id430921107?mt=8
Running Wireshark alongside these iPhone apps shows that they do an ARP scan from XXX.XXX.X.0 all the way to XXX.XXX.X.255. I do not see any ICMP packets go out simultaneously with the "ARPs". This leads me to believe that sending and receiving ARP packets are indeed possible on iOS.
I've thought about a ping sweep, assuming that it will generate ARP requests on its own. However, I will still need a raw socket to listen to the responses, correct?
Questions: What's available for sending/receiving packets at the logical layer? Specifically for sending receiving ARP packets? Am I missing anything fundamental?
Thanks in advance!
ARP requests do go out when I attempted to ping the problematic devices. This was seen with a Wireshark session running alongside the ping scanner. I found that I could not reproduce the "missing devices" I was seeing earlier that led me to ask my original question.
So, to answer my own question: ARP requests are sent per IP address when doing a simple ping scan on my subnet. I would see the ARP request go out (using Wireshark) as well as the ping request. If you need to generate an ARP request, simply send out a ping.
Even if the "problematic" device won't respond to ping requests, the ARP table will be notified of its existence.
You can't do what you want to do, and get the app in the AppStore,
since what you are trying to do isn't in the public API.
So one thing you could do, for testing purposes on your own network, or enterprise distributed apps is looking in the private/undocumented APIs.
One such list is maintained at https://github.com/nst/iOS-Runtime-Headers, but I can't vouch for its accuracy.
Good luck!
I am still learning about SIP and all its protocols, specifically trying to integrate PJSIP into an iPhone application to make p2p calls.
I have a question about a peer 2 peer connection using PJSUA. I am able to
make calls perfectly to other clients on my local network by calling directly using the URI:
sip:192...*:5060
I am curious if this will work for
making direct calls to other SIP URIs that are not on the local
network without using server configuration - if not this way, is there another way of making p2p calls without server configuration?
thanks in advance,
You can make calls without server configuration, as a general principle, but something needs configuring. As mattjgalloway points out in the comments below your question, the most robust solution is a can of worms involving ICE which provides a kind of "umbrella" protocol for things like STUN.
Last time I touched this issue, I had the requirement that I couldn't use internet-based SIP servers to help. I came up with the idea of a registry of sorts: your client can define a bunch of "address spaces" with particular routing requirements. For SIP URIs in your LAN, you define no routing; for URIs in your company's VPN-accessed network, you define a route passing through your VPN connection; for everything else you define a route through your internet router.
By "define a route", I mean that when you place a call to a URI in some particular address space, you store what IP will go into a Contact header, what Route headers you might need, and so on.
Thus, the process of making a call becomes:
Look up in the set of address spaces for a match.
Ask that address space for the suitable bits needed to make a workable INVITE (appropriate Contact header details, Route headers, etc.)
Construct a normal INVITE, mutating as necessary for the previous step.
Send the INVITE as normal.
This essentially reproduces half of what ICE would give you, in a manually administrated form. "Half", because this ensures that one SIP agent can make calls such that the SIP routing all works. The missing half is you still need some kind of registrar somewhere, and each agent in your contact list needs to have the necessary setup to receive incoming calls. (If an agent's behind a NATting internet router, the router would need to either run a SIP proxy, or forward ports 5060, 5061 to a particular machine (which might be an agent, or a proxy serving the LAN's agents).
It is, indeed, a large can of worms.
The basic issue is to solve the problem of getting transport ports anywhere on the internet for multimedia traffic.
Many companies/experts have tried to solve this situation. A possible way out of is to buy a domain and setup a basic registrar using YATE or Asterisk on an address accessible from the internet and configure it to also use ICE as needed. Your iphone application at both ends could register automatically to it upon start. Then make P2P calls.
A requirement for the SIP PBX I created for my company was to record all calls passing through it. I solved it by forcing all SIP message to pass through the PBX and to modify the SDP body so the stream passes through it and gets recorded. It works well.
I recently found out that this is not allowed.
Is there any other way to implement call recording and how "wrong" is this in regard to the protocol?
It sounds like you're describing a SIP proxy, more or less a Session Border Controller (SBC). A proxy can modify SDP, though it should be careful in doing so. Typically SBCs will set the media destination to themselves, and proxy the data to the destination. So this is perfectly legal spec-wise (assuming the devices are already coming to your server).
However, "Not allowed" could also mean "recording calls is legally not allowed", which varies a lot state-to-state.
A more conventional way to implement call recording would be to capture the RTP packets on the wire and put them together to create an audio file. There are quite a few tools around to do exactly that and it's even inbuilt into Wireshark.
As far as tweaking with the SDP goes it's definitely not something that is "not allowed" at least not on a technical level. A lot of SIP Proxy's are forced to mangle the IP addresses in SDP when user agents put private IP addresses in them. You'll find most SIP servers out there have some sort of capability in this regard and it's often call NAT mangling or similar.